API
What — プログラム同士をつなぐ窓口
API とは、Application Programming Interface。HTTP 通信を通して、プログラムが直接サービスを利用するための窓口。
頼む側（クライアント）と返す側（サーバー）という役割分担の上に、プログラム向けの窓口を開けたもの。役割分担そのものの話は サーバーとクライアント に書いた。
なぜ窓口が要るのか
API があることで、相手のプログラムの中身を知る必要がなくなる。
もし API がなかったら、相手のコードや DB に直接つながないといけない。そして相手が中身を変えたら、すべてが壊れる。
API はこの密な結合を切って、境界線を「約束」だけにする。言語や環境が違っても、HTTP と JSON でつながる。
ここから下は、他人の API を正しく使うための地図。HTTP の流れ・読み方・認証・実戦の壁、の順に辿れます。
仕組み — 1回の通信で何が起きるか
- サーバーとクライアント — 頼む側と返す側の役割分担。すべての土台
- APIとJobの違い — HTTP で起動する常駐サーバーという理解
- HTTPリクエストの流れ — DNS → TCP → TLS → HTTP の7段階
- HTTPリクエストの構造 — 注文票の4点セット
- HTTPレスポンスの構造 — 返答の3点セットとステータスコード
- リンクの原理 — リンクの実体は URL＋GET。API と同じ仕組み
読み方 — エンドポイントを分解する
- HTTPメソッド — 1行目の動詞5個と判定軸
- REST — 資源（名詞）×メソッド（動詞）で読む流儀
- エンドポイント — メソッド＋パスで決まる操作1つ分の受け口
- クエリパラメータ —
?以降の「見せ方の注文」
認証 — 誰が・していいか
- 認証と認可 — 401（誰か）と 403（していいか）の2段階検査
- 認証トークンの3層 — OAuth2・Bearer・JWT の役割分担の全体図
- JWT — トークンの書式
- Bearer — トークンの渡し方
- OAuth2 — トークンの入手手続き
実戦 — 最初に踏む壁
- curl — ターミナルから HTTP を1回送る実験台
- ページネーション — 一覧APIは全件を返さない
- レートリミット — 429 は「待って再送」
- エラーレスポンス — コード→ボディ→ドキュメントの3段読み
関連
- Tech — 技術トピックの地図へ戻る
Table of contents