REST API 面接の質問と回答（2026年）：メソッド、ステータスコード、設計

REST APIの質問は、他の人が驚かずに使えるインターフェースを設計できるかを試すものです。以下は、基礎からバックエンドやフルスタックの面接で出てくる設計の詳細まで、回答付きの20問です。HTTPメソッドのルールについては、RFC 9110の定義に従いました。

基礎

1. RESTとは何ですか？

RESTは、URLで識別されるリソースを中心に構築され、少数の標準的な操作で操作され、JSONなどの表現で記述される、ネットワークシステムのためのアーキテクチャスタイルです。REST APIはステートレスです。各リクエストはサーバーが処理するために必要な情報を自身に含んでいるため、どのサーバーでもどのリクエストでも処理できます。

2. 実務上、APIを「RESTful」にするものは何ですか？

• URLにはリソースを表す名詞を使う。例えば /orders/42 のように。/getOrder のような動詞は使わない
• 操作には標準のHTTPメソッドを使う
• 意味のあるステータスコード
• ステートレスなリクエスト
• 一貫した表現とエラーの形

面接では、すべてのREST制約に従っている実際のAPIはほとんどなく、目指すのは予測可能な振る舞いであると伝えましょう。

3. 主なHTTPメソッドは何に使いますか？

「安全」とは、そのリクエストがサーバーの状態を変えないことを意味します。「冪等」とは、複数回送っても1回送ったときと同じ効果になることを意味します。

4. 冪等とは何を意味し、なぜ重要ですか？

リクエストを繰り返しても、最終的な状態は1回のリクエスト後と同じになります。これが重要なのは、ネットワークは失敗するからです。クライアントが PUT でタイムアウトした場合、恐れずに再試行できます。注文を作成する POST は2つ作成してしまう可能性があるため、APIはしばしば冪等キーを受け付けます。クライアントが一意のキーを送り、サーバーがそのキーを再び見た場合は保存された結果を返します。

5. PUTかPATCHか？

PUT は送信したボディでリソース全体を置き換え、省略したフィールドはクリアまたはリセットされます。PATCH は送信したフィールドだけを変更します。小さな更新には PATCH を、クライアントが完全な表現を保持している場合は PUT を使います。

ステータスコードとエラー

6. どのステータスコードを、いつ使いますか？

よくある追加質問は、401と403の違いです。401は「あなたが誰か分からない」、403は「あなたが誰かは分かっているが、これはできない」という意味です。

7. APIはエラーをどのように返すべきですか？

適切なステータスコードと一貫したボディを使います。良いエラーボディには、安定した機械可読なコード、人間向けのメッセージ、そしてバリデーションエラーの場合はどのフィールドが失敗したかが含まれます。スタックトレースや内部の詳細をクライアントに漏らしてはいけません。

8. バリデーションはどのように扱いますか？

クライアント側でもバリデーションする場合でも、サーバー側でバリデーションします。可能であればすべての問題を一度に返し、ユーザーが1つずつ修正しなくて済むようにし、400または422を一貫して使います。

設計

9. リレーションシップのためのURLはどのように設計しますか？

子リソースが親の下でのみ意味を持つ場合はネストします（例：/users/7/orders）。ネストは浅く保ちます。1～2階層を超えたら、子リソースを直接公開し（例：/orders/42）、クエリパラメータでフィルタリングします（例：/orders?userId=7）。

10. リストのページネーションはどのように行いますか？

大規模または頻繁に更新されるデータには、カーソルページネーションが一般的な答えです。次のカーソルと、さらに結果があるかどうかのヒントを返します。

11. フィルタリングとソートはどのように行いますか？

クエリパラメータを使用します（例：?status=open&sort=-created_at）。許可するフィールドをホワイトリスト化し、インデックスのない列や機密性の高い列の露出を防ぎ、クエリを高速に保ちます。

12. APIのバージョニングはどのように行いますか？

どれを選んでも、バージョン内で破壊的変更を避けましょう。フィールドの追加は通常安全ですが、フィールドの削除や名前変更は安全ではありません。

13. HATEOASとは何ですか？

レスポンスに関連アクションへのリンクを含めることで、クライアントはURLをハードコードする代わりに、次に何ができるかを発見できます。RESTの定義の一部ですが、完全に実装しているAPIはほとんどありません。知識として知っていること、そしてほとんどのチームはドキュメントとOpenAPI記述を使っていることを伝えましょう。

セキュリティとパフォーマンス

14. APIの認証はどのように行いますか？

一般的な選択肢は、シンプルなサーバー間通信向けのAPIキー、JSON Web Tokenなどのベアラトークン、ユーザーがアプリにデータへのアクセスを許可する場合のOAuth 2.0です。常にHTTPSを使用しましょう。URLはログに残るため、シークレットをURLに含めないようにします。

15. 認証と認可の違いは何ですか？

認証はあなたが誰であるかを証明することです。認可は何をすることを許可されているかを決めることです。失敗の仕方が異なります。トークンがないか無効な場合は401、有効なトークンでも権限がない場合は403です。

16. APIを悪用からどのように保護しますか？

キーごとまたはIPごとのレート制限、リクエストサイズの制限、入力バリデーション、タイムアウト、異常なトラフィックの監視などです。429とRetry-Afterヘッダーを返し、クライアントに再試行のタイミングを知らせます。

17. APIにおけるHTTPキャッシュはどのように機能しますか？

レスポンスには、レスポンスを再利用できる期間を示すCache-Controlヘッダーを含めることができます。ETagはレスポンスのバージョンを識別します。クライアントはそれをIf-None-Matchで送り返し、何も変更がなければサーバーはボディなしで304 Not Modifiedを返します。帯域幅と負荷を節約できます。

18. CORSとは何ですか？

サーバーが許可しない限り、ブラウザはWebページが異なるオリジンからのレスポンスを読み取ることをブロックします。サーバーはAccess-Control-Allow-Originなどのヘッダーを送信し、どのオリジンがレスポンスを読み取れるかを示します。これはサーバーではなくブラウザによって適用されるため、ブラウザ以外のクライアントからAPIを保護するものではありません。

実践

19. RESTかGraphQLかgRPCか？

最良の答えは、勝者を選ぶのではなく、状況を挙げることです。

20. APIのドキュメント化とテストはどのように行いますか？

OpenAPI仕様で記述し、ドキュメントとクライアントコードを生成できます。3つのレベルでテストします。ロジックの単体テスト、実際のデータベースに対する統合テスト、破壊的変更を検出するコントラクトテストです。無効な入力や期限切れトークンなど、失敗ケースも試しましょう。

準備の方法

1. ホワイトボードで小さなAPI（ToDoリストや注文システムなど）を、URL、メソッド、ステータスコード、1つのエラーレスポンスを含めて設計できるようにしましょう。
2. 冪等性とページネーションは完全に理解しておきましょう。最もよく出題されます。
3. 自分が構築または使用したAPIについてのストーリーと、次回避けたい1つのミスを準備しましょう。

関連する練習として、Spring Boot面接質問、Node.js面接質問、システム設計面接質問、コンピュータネットワーク面接質問のガイドもご覧ください。

声に出して、自分の言葉で練習しましょう。後で文字起こしを確認すると、どこで話が脱線したり要点を外したりしたかが分かります。ライブ面接や評価では、AIツールに関する雇用主のルールに従ってください。