リソース URI は、アクションではなく 「もの」への名詞ベースのパス のように読めるべきです。HTTP メソッドがすでに動詞を供給するので、URI はリソースを明確かつ一貫して識別するだけでよいのです。
リソース URI は、アクションではなく 「もの」への名詞ベースのパス のように読めるべきです。HTTP メソッドがすでに動詞を供給するので、URI はリソースを明確かつ一貫して識別するだけでよいのです。
GET /users/42 — GET /getUser?id=42 ではなく。メソッド (GET) が動詞です。/users はコレクション、/users/42 は 1 つのメンバー。どこでも複数形を保つと予測可能になります。/users/42/orders = 「user 42 に属する order」。kebab-case、小文字を使う。 /blog-posts、/blogPosts や /Blog_Posts ではなく。/users?role=admin&sort=-created_at。/users ユーザーのコレクション
/users/42 1 人のユーザー
/users/42/orders user 42 に属する order (サブコレクション)
/users/42/orders/1001 その user の特定の order
/orders/1001 同じ order、トップレベルでもアドレス指定可能
GET /users/42/orders?status=shipped&sort=-created_at&page=2 HTTP/1.1
Accept: application/json
1〜2 レベルを超える深いネストは避けます — /users/42/orders/1001/items/5/reviews は脆くなります。order が独自の ID を持てば、/orders/1001 を優先します。CRUD に合わないアクション (例: 「メール送信」) には、コントローラ風のサブリソースが許容されます: POST /users/42/verify-email。
一貫した命名は API を直感的に感じさせます — /users と /users/42 を見た開発者は、ドキュメントを読まずに /products と /products/99 を正しく推測できます。面接官はこれで、あなたが RPC 呼び出し (/doThisThing) ではなく リソース で考えるか (REST の考え方) を測ります。最も一般的なアンチパターン — パスの動詞、一貫しない複数形化、深くネストした URL — はすべて API を学び保守しにくくし、REST の uniform-interface 制約を内面化していない開発者を示唆します。良い URI 設計は関心事も分離します: 識別はパスに、フィルタとページネーションは query string に置くことで、キャッシュとルーティングがきれいに保たれます。
ジュニアからシニアまで、詳細な回答付きのIT面接質問ライブラリ。
寄付する