エンドポイント
What — 「メソッド＋パス」で決まる操作1つ分の受け口
エンドポイントは、API が公開している操作1つ分の受け口。「メソッド＋パス」の組で1つと数える。
GET /users/42 ← 42番を見る受け口
DELETE /users/42 ← 42番を消す受け口
パスが同じでもメソッドが違えば別のエンドポイント。「何に対して」がパス、「何をしろ」がメソッドで、2つ揃って初めて操作が1つに決まるからだ。
サーバーとの違い — 住所と建物の関係
サーバーは応える側の機械そのもの、エンドポイントはその機械が公開している受け口の指定で、1対1に対応しない。
- 1台のサーバーが何十個ものエンドポイントを持つ
- 逆に、1つのエンドポイントの裏で機械が10台動いていることもある（負荷分散）
役所でいえば、建物が api.github.com（サーバー）、中に並ぶ「住民票の窓口」「印鑑証明の窓口」がエンドポイント。
graph LR
C[クライアント]
subgraph S["サーバー（api.github.com）"]
E1["GET /users/42<br>42番を見せる窓口"]
E2["DELETE /users/42<br>42番を消す窓口"]
E3["POST /repos<br>リポジトリを作る窓口"]
end
C -->|"メソッド＋パスで窓口を名指し"| E1
C -.-> E2
C -.-> E3
どこで出てくるか
- API ドキュメント — 実質エンドポイントの一覧表。「この API に何ができるか」＝受け口が何個あるか
- 実際に叩く URL — Base URL（
https://api.github.com）にパスを足したものが、受け口までの完全な住所になる - エラーの切り分け —
404は「そのエンドポイントが無い」。パスの打ち間違いをまず疑う
この知識をいつ使うか — 初見の API の全体像を掴む
初見の API で何ができるか知りたければ、ドキュメントのエンドポイント一覧を眺める。REST に従う API なら「資源×メソッド」の掛け算で読めるので（REST）、一覧が長くても規則的に頭に入る。
落とし穴を1つ：セキュリティの文脈の「エンドポイント」は社員の PC やスマホなど末端の端末を指す（EDR ＝ Endpoint Detection and Response）。API の受け口とは別物なので、相手の文脈で切り替える。
関連
- API — API まわりの地図。窓口という考え方もここに
- REST — 資源×メソッドでエンドポイントを読む
- HTTPリクエストの構造 — メソッドとパスが何者か