バックエンド開発 / 約25分
REST APIの一貫性設計
なぜこれを学ぶか
APIは「一度公開したら簡単には変えられない」契約です。場当たり的な命名は後の開発者（未来の自分含む）を苦しめます。
URLは 名詞の複数形 でリソースを表します: /users/123/orders 。動詞（/getUser）は使いません。操作はHTTPメソッド（GET/POST/PATCH/DELETE）で表現します。
HTTPステータスコードを正しく使いましょう。200 で {success: false, error: ...} を返すAPIは監視ツールと相性が悪く、クライアント側の処理も複雑になります。
よく使うコード: 200 成功、201 作成、400 リクエスト不正、401 未認証、403 権限なし、404 存在しない、409 競合、422 バリデーションエラー、500 サーバーエラー。
ページネーションは最初から設計に入れましょう。GET /users?cursor=abc&limit=20 のような カーソル方式 は、データ追加があっても重複・欠落が起きにくい方式です。
破壊的変更が必要な時は バージョニング（/v1/users）や後方互換の維持戦略が必要です。「追加は安全、削除・変更は危険」と覚えましょう。
重要ポイント
- URLは名詞、操作はHTTPメソッド
- ステータスコードを正しく使う（200でエラーを返さない）
- 追加は安全、削除・変更は危険（後方互換）
理解度チェック
選ぶと即座に解説が表示されます。
注文APIで「在庫不足で注文を作成できなかった」場合、返すべきステータスコードは？
ヒントを見る
まず大分類を考えます: リクエスト自体は正しい（4xx系）？ サーバーの障害（5xx系）？ 成功（2xx系）？ その上で「現在のリソース状態と矛盾している」ことを表すコードはどれでしょう。
コーディング演習実際に書く
ステータスコードの対応表をコードで実装してください。状況を表す文字列を受け取り、適切なHTTPステータスコード（数値）を返します。対応: 'success'→200, 'created'→201, 'bad_request'→400, 'unauthorized'→401, 'forbidden'→403, 'not_found'→404, 'conflict'→409。未定義の状況は 500 を返してください。
スキルセルフチェック
このレッスンの内容をどの程度理解できましたか？