REST API 面接でよく聞かれる 25 の質問と回答

ソフトウェア開発業界では、統合がアプリケーション設計において重要な役割を果たします。そのための主要なテクノロジーの 1 つがREST APIです。REST API の知識は、すべての技術スペシャリストにとって重要なスキルです。この記事では、就職面接の準備とスキルの向上に役立つ 25 の REST API の質問を紹介します。ぜひお読みください。

まず、面接官は通常、REST API に関する質問を理論的なものと実践的なものに分けています。最初に、用語と HTTP リクエストメソッドに関する理論的な質問を 2 ～ 3 問行い、その後、リクエストを作成する実践的なタスクが与えられます。

この記事にはよく聞かれる理論的な質問が含まれています。次の記事では、REST API に関連する実際のタスクの例を公開する予定です。面接でどのような質問を受けるかは事前にわかりませんが、典型的な質問のリストに取り組む過程で、おそらくトピックについてより深く掘り下げ、REST API に関する知識を向上させることができると確信しています。

それでは、基本的な用語から始めて、より複雑な質問のセクションに進み、簡単なものから複雑なものへと進みましょう。

1. REST とは何ですか?

回答: REST を指すときに使用される用語が 3 つあり、これらは同じものとみなされることが多いですが、これは完全に正しいわけではありません。これらの用語は、REST、REST API、および RESTful API です。次に、REST に関する回答を示します。REST は Representational State Transfer の略で、フロントエンドや外部システムとの統合を持つアプリケーションを開発するための、HTTP プロトコル (Hypertext Transfer Protocol) に基づくアーキテクチャ スタイルです。REST は、設計される API サービスが従うべきガイドラインを説明しています。これらの原則により、HTTP を使用してクライアントとサーバーの間で要求が渡されることが保証されます。

2. REST API とは何ですか?

回答: API は、個々のアプリケーションが通信してデータを交換できるようにするプログラミング インターフェースです。たとえば、食品配達アプリは Google Maps API を使用して配達員の位置を追跡し、地図上に表示できます。REST API は、REST の原則に従う API で、すべてのデータをリソースとして扱い、それぞれが一意の Uniform Resource Identifier (URI) で表されます。

3. RESTful API とは何ですか?

回答: RESTful API は、REST のルール (または「原則」とも言う) に従って設計された API です。言い換えると、REST API と RESTful API の違いは用語上の違いです。前者は REST ルールのセットを指し、後者は REST ルールに従った特定の API の実装を指します。RESTful API という用語は、簡潔さのために REST API または REST に置き換えられることがよくあります。システム アナリストがアプリケーション ダイアグラムに REST というラベルの付いた矢印を描く場合、それは RESTful API を意味します。

4. REST の 2 つの主な原則は何ですか?

回答: REST API リクエストは、次の 2 つの基本原則に従う必要があります。クライアントとサーバーの分離: クライアントとサーバー間のやり取りは、リクエストと応答の形式で実行されます。クライアントのみがリクエストを送信でき、サーバーのみが応答を送信して、互いに独立して動作できます。単一プロトコル: クライアントとサーバー間のやり取りは、単一のプロトコルを使用して実行する必要があります。REST の場合、このプロトコルは HTTP です。

5. REST のその他の原則についてご存知ですか?

回答: 少なくとも 4 つの原則を挙げることができます。REST API リクエストはサーバー上に状態を保存せず、サーバーのレイヤーを通過してキャッシュできます。また、サーバーの応答で実行可能コードをクライアントに送信することもできます。サーバー ステートレス: サーバーは過去のリクエスト/応答に関する情報を保存しません。各リクエストと応答には、対話を完了するために必要なすべての情報が含まれています。ステートレス通信により、サーバーの負荷が軽減され、メモリが節約され、パフォーマンスが向上します。階層化システム: クライアントと API サーバーの間に、レイヤーの形で追加のサーバーを配置して、さまざまな機能を実行できます。REST 原則に基づいて構築されたシステムでは、レイヤーはモジュール式であり、クライアントとサーバー間の通信に影響を与えることなく追加および削除できます。キャッシュ可能性: サーバーの応答は、そのリソースがキャッシュ可能かどうかを示します。これにより、クライアントは任意のリソースをキャッシュしてパフォーマンスを向上させることができます。オンデマンド コード: サーバーは、クライアント アプリケーション内で実行するために、応答でクライアントに実行可能コードを送信できます。

6. リソースとは何ですか?

回答: REST では、サーバー側でアクセス可能なすべてのオブジェクトがリソースとして指定されます。リソースとは、タイプ、関連付けられたデータ、サーバー上の他のリソースとの関係、およびリソースを操作するために使用できるメソッドのリストを持つオブジェクトのことです。たとえば、リソースには、HTML またはテキスト ファイル、データ ファイル、画像またはビデオ、実行可能コード ファイルなどがあります。リソースは、Uniform Resource Identifier (URI) によって識別されます。クライアントは、HTTP 要求で URI を使用してリソースにアクセスします。

7. URLとは何ですか?

回答: URI は Uniform Resource Identifier の略です。これは、サーバー上のリソースを識別する文字列です。各リソースには固有の URI があり、HTTP リクエストにこれを含めると、クライアントはそのリソースにアクセスしてアクションを実行できます。URI でリソースを参照するプロセスは、「アドレス指定」と呼ばれます。

8. CRUD とは何ですか?

回答: CRUD は「作成、読み取り、更新、削除」の略です。これらは、REST API を介してデータベースで実行できる 4 つの主なアクションです。各アクションには独自の HTTP リクエスト メソッドがあります。

• 作成 = POST
• 読む = GET
• 更新 = PUT
• 削除 = 削除

9. サーバー応答のペイロードとは何を意味しますか?

回答: HTTP 応答ペイロードは、クライアントによって要求されたリソース データを指します。これは、簡単に「HTTP 応答ペイロード」とも呼ばれます。このデータは、サーバーが提供する内容に応じて、JSON、XML、HTML、画像、ファイルなどになります。

10. REST メッセージングとは何ですか?

回答: REST におけるメッセージングとは、クライアントとサーバー間のメッセージの交換を指します。通信は常に、クライアントがサーバーに HTTP 要求を行うことから始まります。サーバーはこの要求を処理し、要求のステータスとクライアントが要求したリソースを示す HTTP 応答を返します。

11. REST のメッセージ ブローカーとは何ですか?

回答: REST のコンテキストでは、「メッセージ ブローカー」という用語は、分散アプリケーション内のさまざまなコンポーネントまたはシステム間でメッセージを渡す役割を果たすミドルウェアです。ブローカーは、さまざまなシステム モジュール間での非同期データ交換、メッセージ キューイング、およびメッセージ処理を提供できます。

メッセージ ブローカーは、非同期操作の管理や通知の送信に使用できます。メッセージ ブローカーはネイティブの REST 要素ではありません。REST は、HTTP 要求を使用したクライアントとサーバー間の同期通信に重点を置いているためです。

12. REST ではどのような HTTP リクエスト メソッドがサポートされていますか?

回答: HTTP リクエスト メソッドは、サーバーがリソースに対して実行する目的のアクションを指定します。REST では、クライアントからサーバーに HTTP リクエストを行うための主な方法が 4 つあります。

• GET: サーバーからリソースを要求します。このメソッドは読み取り専用です。
• POST: サーバー上に新しいリソースを作成します。
• PUT: サーバー上の既存のリソースを更新します。
• DELETE: サーバーからリソースを削除します。

13. POST メソッドと PUT メソッドの違いは何ですか?

回答: POST はサーバー上にリソースを作成するためのもので、PUT は特定の URI のリソースを別のリソースに置き換えるためのものです。すでにリソースが関連付けられている URI で PUT を使用すると、PUT はそのリソースを置き換えます。指定された URI にリソースがない場合、PUT はリソースを作成します。PUT はべき等性があり、複数回呼び出しても作成されるリソースは 1 つだけです。これは、各呼び出しで既存のリソースが置き換えられる (または置き換えるものがない場合は新しいリソースが作成される) ためです。POST はべき等性がありません。たとえば、POST を 10 回呼び出すと、サーバー上に 10 個の異なるリソースが作成され、それぞれに独自の URI があります。めったに使用されませんが、POST 応答はキャッシュできますが、PUT 応答はキャッシュできません。POST 要求は一般にキャッシュ不可能であると考えられていますが、データの「鮮度」に関する明確な情報が含まれている場合はキャッシュできます。より詳細な回答としては、データが「最新」で Content-Location (en-US) ヘッダーが設定されている場合は、POST (または PATCH) 要求の応答をキャッシュできますが、これが実装されることはほとんどありません。したがって、可能であれば POST キャッシュは避ける必要があります。

14. HTTP リクエストの主な部分は何ですか?

回答: REST では、HTTP リクエストの基本的なコンポーネントは次のようになります: リソースに対して行われるリクエスト メソッド (GET、POST、PUT、DELETE など)。 サーバー上の要求されたリソースを識別する URI。 HTTP バージョン (サーバー応答に含まれるバージョン)。 HTTP リクエスト ヘッダーには、ユーザー エージェント、クライアントが受け入れるファイル形式、リクエスト本文の形式、言語、キャッシュ設定など、リクエストに関するメタデータが含まれます。 HTTP リクエストの本文には、リクエストに関連付けられたすべてのデータが含まれます。これは、リクエストが POST または PUT メソッドを使用してサーバー上のデータを変更する場合にのみ必要です。

15. HTTP 応答の主な部分は何ですか?

回答: HTTP 応答はサーバーからクライアントに送信されます。HTTP 応答は、要求されたアクションが完了した (または完了していない) ことと、要求されたリソースが配信されたことをクライアントに通知します。HTTP 応答には、次の 4 つの主要なコンポーネントがあります。使用される HTTP バージョン。要求ステータスと HTTP 応答ステータス コードを含むステータス バー。時間、サーバー名、ユーザー エージェント、返されたリソース ファイル形式、キャッシュ情報など、応答に関するメタデータを含む HTTP 応答ヘッダー。クライアントが要求したリソースに関するデータを含む HTTP 応答本体。

16. HTTPサーバーの応答が成功した場合のコードを少なくとも3つ挙げてください。

回答: リクエストが正常に処理されると、サーバーは次の操作ステータス コードを返します。

• 200 OK: リクエストは正常に完了しました。
• 201 作成済み: リクエストが成功し、リソースが作成されました。
• 202 承認済み: このステータスは、サーバーがクライアントの要求を受け入れたが、処理を完了していないことを意味します。処理は非同期で行われる場合があります。

17. リクエストをリダイレクトするときに、少なくとも 4 つのサーバー HTTP 応答コードを指定します。

回答: リクエストをリダイレクトするときに、サーバーは次のステータス コードを返します。

• 301 恒久的に移動: このステータスは、要求されたリソースが別の URL に恒久的に移動されており、クライアントがリソースにアクセスするには新しい URL にアクセスする必要があることをクライアントに通知します。
• 302 見つかりました: このステータスは、リソースが一時的に別の URL に移動されており、クライアントは一時的に新しい URL を使用する必要があることを示します。
• 307 一時リダイレクト: 302 と似ていますが、クライアントは新しい URL にアクセスするときに同じリクエスト メソッドを使用する必要があります。
• 308 永続リダイレクト: 301 と似ていますが、クライアントは新しい URL にアクセスするときに同じリクエスト メソッドを使用する必要があります。

18. HTTP サーバー応答が失敗した場合のコードを少なくとも 4 つ挙げてください。

回答: リクエストが失敗すると、サーバーは次のコードを返します。

• 400 不正なリクエスト: 入力ミスやデータの欠落など、リクエスト内のエラーが原因でリクエストが完了しませんでした。
• 401 権限なし: クライアントが認証されていないか、要求されたリソースにアクセスする権限がないため、要求は完了しませんでした。
• 403 禁止: クライアントは認証されていますが、要求されたリソースにアクセスする権限がないため、要求は完了しませんでした。
• 404 見つかりません: サーバーが要求されたリソースを見つけられなかったため、要求は完了しませんでした。

19. 少なくとも 3 つのサーバー エラー コードを挙げてください。

回答: サーバーにエラーが発生すると、サーバーは次のコードを返します。

• 500 内部サーバー エラー: サーバーで予期しない問題が発生したため、要求は完了しませんでした。

• 502 不正なゲートウェイ: アップストリーム サーバーからの応答が正しくないため、要求は完了しませんでした。

• 503 サービスは利用できません: メンテナンス、過負荷、またはその他の一時的な障害のため、サーバーは要求を処理できませんでした。

  
  

20. RESTとGraphQLの違いは何ですか？

回答: GraphQL は、クライアントが必要なデータのみをクエリできるクエリ言語です。GraphQL では、クライアントが受信するデータの構造と形式を定義し、サーバーはそのリクエストに従ってデータを返します。主な違いは、REST ではリソースごとにリクエストとレスポンスの形式が固定されているのに対し、GraphQL ではクライアントがリクエストを定義して必要な情報のみを取得できるため、より効率的で柔軟に使用できることです。

21. REST と SOAP の違いは何ですか?

回答: REST と SOAP (Simple Object Access Protocol) は、API を構築するための 2 つのアプローチです。これらには 3 つの主な違いがあります。

• SOAP は、安全な API を構築するための厳格なプロトコルです。REST はプロトコルではなく、REST 原則と呼ばれる一連のガイドラインによって規定されたアーキテクチャ スタイルです。- REST API は、SOAP API よりも構築が簡単で、軽量で、一般的に高速です。
• SOAP API は REST API よりも安全であると考えられていますが、REST API でもセキュリティ機能を実装して安全性を高めることができます。 - REST では応答をキャッシュできますが、SOAP ではできません。
• SOAP はデータを XML 形式でエンコードします。 - REST では任意の形式でデータをエンコードできますが、最も普及しているのは XML と JSON です。

22. REST と AJAX の違いは何ですか?

回答: 非同期 JavaScript (AJAX) は、Web アプリケーションで使用される一連の Web 開発テクノロジです。基本的に、AJAX を使用すると、Web ページはサーバーにリクエストを送信し、ページ全体を更新せずにページのインターフェイスを更新できます。

AJAX クライアントはリクエストで REST API を使用できますが、AJAX は REST API のみで動作する必要はありません。REST API は、AJAX を使用するかどうかに関係なく、任意のクライアントと通信できます。

HTTP リクエストとレスポンスを使用してメッセージを交換する REST とは異なり、AJAX は JavaScript に組み込まれた XMLHttpRequest オブジェクトを使用してリクエストをサーバーに送信します。サーバーの応答はページの JavaScript コードによって実行され、そのコンテンツが変更されます。

23. REST API 開発における「コントラクト ファースト」アプローチとは何ですか?

回答: REST API 開発に対するコントラクト ファースト アプローチは、実際の開発が始まる前に API 仕様とコントラクトを作成して定義する方法です。このコントラクトは、クライアントが API と対話する方法と、さまざまなリクエストからどのような結果が期待されるかを定義する重要なドキュメントとして機能します。

24. Contract First の利点は何ですか?

回答: Contract First アプローチの利点は次のとおりです。

• 明確な API 定義: API 仕様と契約は、API がクライアントと対話する方法を定義します。
• リスクの軽減: 顧客との契約の事前承認により、誤解や API 開発の期待に応えられないリスクを軽減できます。
• ドキュメントの改善: 契約テキストは多くの場合 API のドキュメントとして機能し、使用と統合が容易になります。

25. REST API 開発に対するコードファースト アプローチとは何ですか?

回答: REST API 開発に対するコード ファースト アプローチは、最初に API 機能を開発し、その機能に基づいて API 仕様を自動的に生成する方法論です。コード ファースト アプローチの特徴は、開発者が API ロジックの作成に重点を置き、そのロジックに基づいてドキュメントと仕様を自動的に作成できるツールを使用することです。

一般的に、コード ファーストとコントラクト ファーストの両方のアプローチを同じ API 開発プロジェクト内で組み合わせることができます。この場合、コード ファーストはラピッド プロトタイピングに使用され、その後コントラクト ファーストを使用して契約を正式化します。

この記事が、就職面接の準備や REST API に関する知識の復習に役立つことを願っています。