## What — 「メソッド＋パス」で決まる操作1つ分の受け口 エンドポイントは、API が公開している**操作1つ分の受け口**。「メソッド＋パス」の組で1つと数える。 ``` GET /users/42 ← 42番を見る受け口 DELETE /users/42 ← 42番を消す受け口 ``` パスが同じでもメソッドが違えば別のエンドポイント。「何に対して」がパス、「何をしろ」がメソッドで、**2つ揃って初めて操作が1つに決まる**からだ。 ## サーバーとの違い — 住所と建物の関係 サーバーは応える側の**機械そのもの**、エンドポイントはその機械が公開している**受け口の指定**で、1対1に対応しない。 - 1台のサーバーが何十個ものエンドポイントを持つ - 逆に、1つのエンドポイントの裏で機械が10台動いていることもある（負荷分散） 役所でいえば、建物が `api.github.com`（サーバー）、中に並ぶ「住民票の窓口」「印鑑証明の窓口」がエンドポイント。 ```mermaid 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リクエストの構造]] — メソッドとパスが何者か