中級ではRESTと設計の勘所を見ました。上級では、契約・進化・大規模運用へ。
上級の解説は準備中のため、上級の内容を表示しています。
概要 — まず全体をつかむ
詳細 — 1段階ずつ追う
契約駆動という発想
APIは「先に契約（仕様）を決め、両者がそれに従う」もの。
- 契約の記述 — OpenAPI（REST）、protobuf（gRPC）、GraphQLスキーマ
- 契約テスト — 提供側と利用側の食い違いを、テストで自動検出
- 後方互換 — 追加はOK、削除・意味変更はNG。破るならバージョン
大規模なやり取り
- 検証→認証認可→処理→応答 を、契約に沿って
- 冪等キー で再送に耐える
- カーソルページング で安定した分割取得
- 部分応答・フィールド選択 で過不足を減らす
形式ごとの勘所
- REST／GraphQL／gRPC — 汎用・柔軟取得・高速型付き、で使い分け
- GraphQLのN+1 — DataLoaderでバッチ＋キャッシュ
- レート制限 — トークンバケット／リーキーバケットで平準化
- スキーマ進化 — protobufのフィールド番号、GraphQLのdeprecated
- BFF — 画面ごとに最適な窓口を用意する層
⚠️ 落とし穴
- 破壊的変更 — 依存クライアントが壊れる
- チャッティAPI — 往復が多すぎて遅い（まとめる／BFF）
- over／under-fetching — RESTで余分／不足
- バージョン乱立 — v1〜v9が並走し保守不能に
理解度チェック
そのまま解けます（成績は保存されません）。無料アカウントを作ると、学習の記録と進捗の山登りが始まります。
問1. 大量データのページングで、ズレや重複に強いのは？
問2. GraphQLで各フィールドが個別にDBを叩いてしまうN+1を、まとめて解決する定番は？
問3. 後方互換を保つために「やってよい変更」はどれか？
問4. レート制限で流量を平準化する代表的なアルゴリズムはどれか？
問5. BFF（Backend for Frontend）層の役割に最も近いのはどれか？
問6. 「チャッティなAPI」が遅くなりやすい根本原因はどれか？
問7. REST APIの契約（仕様）を機械可読に記述する代表的な仕様の名前を答えてください。
問8. gRPCで契約の記述とデータのシリアライズに使う仕組みを答えてください。