目次[隠す][見せる]
- 1.RESTで何がわかる?
- 2. REST API とはどういう意味ですか?
- 3. URI とは正確には何ですか?
- 4. RESTful Web サービスの特徴は?
- 5. REST の指針となる原則は何ですか?
- 6. REST がサポートする HTTP メソッドに言及してください。
- 7. 一貫したインターフェースによる制限について説明してください。
- 8. REST リソースとは正確には何ですか?
- 9. あなたにとって JAX-RS とは何ですか?
- 10. AJAX と REST の違いは何ですか?
- 11. RESTful Web サービスの欠点をいくつか挙げていただけますか?
- 12. PUT 手法と POST 手法の違いは何ですか?
- 13. RESTful Web サービスをどのようにテストしますか?
- 14. 現実世界で REST API を説明します。
- 15. マイクロサービス アーキテクチャはどのように機能しますか?
- 16. キャッシングとは正確には何ですか?
- 17. ペイロードを記述します。
- 18. SOAP と REST を区別しますか?
- 19.トランスポート層セキュリティ プロトコル (TLS) を REST で使用できますか?
- 20.べき等メソッド: それらは何ですか? それは RESTful Web サービスの世界にどのように適用されるのでしょうか?
- 21. HTTP 基本認証の機能は何ですか?
- 22. マイクロサービス アーキテクチャを作成するには、GraphQL が最適だと思いますか?
- 23.安全なHTTPメソッドとべき等HTTPメソッドの主な違いは何ですか?
- 24. JAX-RS API は、RESTful ルート リソース クラスによって何を意味しますか?
- 25. Postman とは正確には何ですか? なぜ使用されるのですか?
- 26. REST API はどのように安全に保たれていますか?
- まとめ
REST の進化により、API は信じられないほどアクセスしやすくなり、その強みと可能性もすべて明らかになりました。 REST API は、リソース指向のアーキテクチャであるため、簡単に作成してキャッシュできます。
さらに、RESTful API は、クラウド コンピューティングやマイクロサービス ベースの設計など、他の重要な開発の先駆者でした。
したがって、RESTful サービスを採用する企業に競争力を提供する方法を考えると、REST API 開発者が今日求められていることは驚くべきことではありません。 REST API は人気のある設計トレンドです。
多くの IT 企業は、REST API の知識を求めています。 ソフトウェア開発者 技術面接でそれについて尋ねます。
REST API 開発分野で働きたい場合に、さまざまな企業での面接の準備に役立つ、最も一般的な REST API 面接の質問のいくつかを次に示します。
1.RESTで何がわかる?
REST は、ハイパーテキスト転送プロトコル (HTTP) に基づく Web ベースのアプリケーションを設計するためのアーキテクチャ パラダイムです。
REST は、Web サービスが RESTful と見なされるために満たす必要がある特定の標準を定義します。 これらの推奨事項は、標準化された HTTP プロトコルを使用して、クライアントとサーバーの間で要求とリソースが迅速かつ効果的に送信されることを保証します。
2. REST API とはどういう意味ですか?
アプリケーション プログラミング インターフェイスとして知られるソフトウェア間のリンクにより、独立したプログラム間の通信とデータ共有が可能になります。 たとえば、ニュース Web サイトは Twitter API を使用して、関連するツイートを自動的に検出し、それらをニュース記事に統合することができます。
REST 原則に準拠する API は REST API と呼ばれ、RESTful API と呼ばれることもあります。 REST API では、データの各部分がリソースとして処理され、個別の標準リソース ID (URI) が与えられます。
たとえば、Twitter API は、すべてのツイートを、クライアントが利用できる取得可能なリソースにします。 ユーザーは Twitter API を使用して、ツイートを投稿したり、その他の Web サイト タスクを実行したりできます。
3. URI とは正確には何ですか?
A コンピュータネットワーク リソースは、URI または統一リソース識別子を使用して参照できます。 これは、あるリソースを別のリソースから分離する手段として機能します。 ソースがオンラインである場合とそうでない場合があります。
URI は標準的な構造であるため、さまざまなタイプのリソースに簡単に接続できます。 リソースの場所または名前は、文字列とともに URI に含まれます。
URI は、パス、スキーム、クエリ、およびその他の要素で構成されますが、プロトコルは含まれません。
プロトコルを使用して、URL (Uniform Resource Locator) を使用してインターネット上のリソースを検索したり、インターネット経由でアクセスしたりします。
4. RESTful Web サービスの特徴は?
- クライアント サーバー パラダイムは、サービスの基盤です。
- サービスは、URI を使用してリソースにアクセスできます。
- このサービスは、HTTP プロトコルを使用してデータ/リソースを取得し、クエリを実行し、その他のタスクを実行します。
- メッセージングは、クライアントとサーバー間の通信に使用される方法の名前です。
- これらのサービスは、SOAP サービスを使用して REST アーキテクチャ パターンを実装することもできます。
- 同じ種類の繰り返し要求に対するサーバー呼び出しを減らすために、これらのサービスはキャッシングの考え方も採用しています。
5. REST の指針となる原則は何ですか?
REST API は、次の XNUMX つの基準を満たす必要があります。
クライアントとサーバーの分離: クライアントとサーバー間の通信に使用できるのは、一連の要求と応答のみです。 クライアントとサーバーのみが、それぞれ要求と応答を送信できます。 この単純なアイデアにより、両当事者は互いに独立して機能することができます。
統一されたインターフェイス: すべてのクライアント サーバー接続に対して統一されたプロトコルが必要です。 REST のこのプロトコルは HTTP です。 各アプリケーションは同じ言語を使用してデータを要求および送信するため、一貫したインターフェイスにより統合が簡単になります。
ステートレス: サーバーは、ステートレス通信で以前の要求または応答の記録を保存しません。 各要求と応答は、交換を完了するために必要なすべての詳細を提供します。 ステートレス通信により、速度が向上し、メモリが節約され、サーバーの負荷が軽減されます。 さらに、不完全なデータが原因でリクエストが失敗する可能性を回避します。
階層化されたシステム: クライアントと API サーバーの間に存在するサーバーは、レイヤーと呼ばれます。 これらの追加サーバーは、スパムの検出や速度の最適化など、さまざまなサービスを実行します。 REST のレイヤーはモジュール式です。つまり、クライアントと API サーバー間の通信に影響を与えることなく追加および削除できます。
キャッシュ可能: サーバーの回答がリソースがキャッシュ可能かどうかを示している場合、クライアントは任意のリソースをキャッシュして速度を上げることができます。
オンデマンド コーディング: 応答として、API は実行可能なコンピューター コードを顧客に送信できます。 その後、クライアント アプリケーションは独自のバックエンドでコードを実行できます。
6. REST がサポートする HTTP メソッドに言及してください。
REST がサポートする HTTP メソッドは次のとおりです。
- GET: このメソッドは、指定された URL でリソースを要求します。 リクエスト本文は無視されるため、含めないでください。 ローカルまたはサーバー上にキャッシュできる可能性があります。
- POST: このメソッドは、処理のためにデータをサービスに送信します。サービスは通常、新しいリソースまたは変更されたリソースを返します。
- PUT: リソースはリクエスト URL で更新されます。
- DELETE: リソースはリクエスト URL で削除されます。
- オプション: サポートされているメソッドを識別します。
- HEAD: リクエスト URL のメタデータが返されます。
7. 一貫したインターフェースによる制限について説明してください。
クライアントをサーバーから分離するには、一貫したインターフェースが必要です。
一貫したインターフェイスを実現するには、次の XNUMX つの制約が必要です。
- リソースの識別: クライアント リクエストは、標準のリソース ID を使用してリソース (URI) を識別する必要があります。
- これらの表現を使用したリソース操作: クライアントは、サーバーからリソース表現を取得するときに、リソースの状態を変更できるようにするために必要なすべての情報を持っています。
- 自己記述型メッセージ: メッセージには、受信者がメッセージを理解するために必要なすべてのメタデータとその他の情報が含まれます。
- アプリケーション状態エンジンとしてのハイパーメディア: クライアントとサーバー間の通信チャネルは HTML などのハイパーメディアであり、クライアントはサーバーの応答を理解するために API 固有のドキュメントを必要としません。
8. REST リソースとは正確には何ですか?
リソースは、REST アーキテクチャにおける RESTful Web サービスの基本コンポーネントです。 API クライアントがアクセスする必要があるすべての重要な情報が含まれています。
HTML ページ、画像、ビデオ、または API アクティビティに必要なその他のものなど、あらゆるタイプのリソースに、クライアント/サーバー システムのサーバーを介してアクセスできます。
リソースは、Uniform Resource Identifier によって識別されます。 テキスト、JSON、または XML はすべて、許容されるリソースの表現です。 とはいえ、表現の形式に制限はありません。
9. あなたにとって JAX-RS とは何ですか?
JAX-RS として知られる Java API for RESTful Web Services のおかげで、Java で RESTful Web サービスを作成するのがより簡単になります。 開発者は、提供されている注釈を使用して、リソースとそれらに対して実行できる操作を説明できます。
10. AJAX と REST の違いは何ですか?
Ajax:
- Ajax は、動的な更新を可能にするテクノロジのグループです。 ユーザーインターフェース ページをリロードせずに要素を表示します。
- Ajax は、クライアントとサーバー間の非同期通信を取り除きます。
残り:
- REST は、サーバーとクライアント間の通信を要求します。
- リソースの使用率は、REST で使用される URL 構造と要求/応答パターンにとって重要です。
11. RESTful Web サービスの欠点をいくつか挙げていただけますか?
サービスはステートレスの概念に準拠しているため、セッションを維持できません。 (クライアントは、セッションのシミュレーション全体でセッション ID を渡す責任があります。)
セキュリティ制約は REST の基本ではありません。 それを使用するプロトコルは、セキュリティ上の注意事項を継承します。 そのため、SSL/TLS ベースの認証を統合するなど、セキュリティ対策を講じる際には注意が必要です。
12. PUT 手法と POST 手法の違いは何ですか?
プット:
- PUT 応答のキャッシュはありません。
- 冪等 (つまり、複数のリクエストで同じ結果が得られる)
- リクエストのペイロードがターゲット リソースを更新または置換します。
役職:
- べき等ではない (つまり、複数のリクエストが同じリソースの倍数を生成する)
- Web サーバーは、目的のリソースに基づいて要求のペイロードを処理します。
- 適切なキャッシュ制御ヘッダーが含まれている場合、POST 応答をキャッシュできます。
13. RESTful Web サービスをどのようにテストしますか?
RESTful Web サービスのテストは、Swagger や Postman などの多くのツールで支援できます。 クエリ パラメーター、ヘッダー、応答ヘッダーなどの要求パラメーターの検査は、後者の豊富な機能によって可能になります。
Postman を使用して、エンドポイントにリクエストを送信し、結果を表示できます。 そして、これらの回答から XML と JSON を作成できます。
Postman と Swagger はどちらも、非常によく似た機能を提供します。 一方、Swagger はエンドポイントのドキュメントなどの機能も提供します。
14. 現実世界で REST API を説明します。
- 旅行およびチケット販売の Web サイトは、航空会社が API を通じて提供するフライトのタイミングと価格設定を活用できます。
- マッピング アプリやナビゲーション アプリ (Google マップなど) で使用するために、公共交通機関は多くの場合、API を介してリアルタイムでデータを公開しています。
- 気象アプリケーションは、気象データを交換して気象情報を表示するオープン API を使用します。
- 開発者は、ホストされている多数の API を介して Google マップのマッピング データにアクセスできます。 これらの API は、開発者がアプリや Web サイトにダイナミック マップを埋め込むために使用します。
15. マイクロサービス アーキテクチャはどのように機能しますか?
- さまざまなデバイスを使用して、さまざまな顧客からリクエストが送信されます。
- クライアントの ID を確認した後、ID プロバイダーはセキュリティ トークンを提供します。
- クライアント リクエストは API Gateway によって管理されます。
- システムの素材はすべて静的コンテンツとして保持されます。
- 管理ツールは、ノード上のサービスのバランスと障害をチェックします。
- マイクロサービス間の通信経路の検出は、サービス検出によって支援されます。
- データ センターとプロキシ サーバーは、コンテンツ配信ネットワークと呼ばれる分散ネットワーク システムを構成します。
- リモート サービスは、離れた場所からの情報アクセスを提供します。
16. キャッシングとは正確には何ですか?
後でより迅速にアクセスするために、サーバーの回答のコピーを一時的にどこかに (コンピューターのメモリなど) に保持することをキャッシングと呼びます。
キャッシングは、要求を満たすためにサーバーが実行する必要のある作業量を減らすことで、REST API を使用する際のサーバーの速度を向上させます。 API を利用するアプリケーションは、リソースが必要になるたびに新しいリクエストを送信する必要がないため、キャッシングのおかげでより速く実行されます。
HTTP 応答ヘッダーの Cache-Control フィールドには、再度アクセスする必要がある前にクライアントがリソースをキャッシュできる期間に関する情報が含まれています。
17. ペイロードを記述します。
REST のペイロードは、HTTP 応答の本文に含まれる情報を参照します。 顧客は GET 手法を使用して、問題のデータを要求しました。
たとえば、Twitter API に特定のツイートを要求した場合、ツイート テキストと、ツイートを Web サイトに掲載するために必要なファイルを含むドキュメントがペイロードに含まれます。 さらに、POST メソッドを使用してペイロードを HTTP 要求に含めることができます。
18.差別化する SOAP 対 REST?
- XML のみを処理できる SOAP とは異なり、REST では、XML、テキスト、HTML、画像、ビデオなど、より幅広いリソース形式を使用できます。
- オンライン アプリケーションにとってセキュリティが重要な場合は、SOAP が役に立ちます。 REST は特に安全ではないため、トランザクションを安全に完了する必要がある場合には使用できません。
- SOAP は単なるプロトコルであるため、REST は Web サービスで SOAP を使用できますが、その逆はできません。
- REST は Web サービスの開発に使用されるアーキテクチャ パターンにすぎず、クライアント/サーバーのセットアップ、ステートレス、キャッシュ可能な応答、階層化されたシステム、一貫したインターフェイスなどの特定の制限を順守しますが、SOAP は厳密に準拠する必要がある特定の標準で動作するプロトコルです。に。
- REST は Universal Resource Identifier (URI) を使用しますが、SOAP はサービス インターフェイスを使用してその機能をクライアント アプリケーションに提供します。 SOAP メッセージは情報量が多いため、REST は SOAP よりも必要な帯域幅が低くなります。
19.トランスポート層セキュリティ プロトコル (TLS) を REST で使用できますか?
実際、できます。 REST クライアントとサーバーの通信は TLS を介して暗号化され、プロトコルはクライアントがサーバーを認証する方法も提供します。
Secure Socket Layer の代替であることから、セキュア通信 (SSL) に利用されます。 HTTPS は TLS と SSL の両方と効果的に連携するため、RESTful Web サービスの実装は HTTPS で成功します。
REST は、実装するプロトコルの特性を継承します。これは、ここで注意すべき点の XNUMX つです。 その結果、セキュリティ保護は REST が使用するプロトコルに依存します。
20.べき等メソッド: それらは何ですか? それは RESTful Web サービスの世界にどのように適用されるのでしょうか?
URI が同じ場合、リクエスト内の一部の HTTP メソッドは、配信が XNUMX 回か複数回かにかかわらず、サーバーに同じ影響を与えます。 冪等テクニックは、これらのテクニックとして知られています。
たとえば、GET メソッドを使用する URI が何回実行されても、サーバーは常に同じ結果を経験します。 冪等メソッドには、GET、PUT、PATCH などがあります。
べき等 HTTP メソッドは、RESTful で利用されるものの一部です。 Webアプリケーション. これらは、RESTful Web サービスのアクティビティの一貫性を保証するために必要です。
REST API を使用する顧客は、REST API が誤って繰り返し要求を行うように強制するコード エラーを作成する可能性があります。 これらの呼び出しは、リソースを悪用する可能性があります。
21. HTTP 基本認証の機能は何ですか?
基本認証を API の一部として使用する場合、ユーザーはユーザー名とパスワードを送信する必要があります。これらはブラウザーによって「ユーザー名: パスワード」の形式で連結され、base64 でエンコードされます。
ブラウザからの HTTP リクエストごとに、エンコードされた値が「Authorization」ヘッダーの値として配信されます。 認証情報はエンコードされているだけなので、HTTPS リクエストを送信する際はこのフォームを使用することをお勧めします。HTTPS リクエストは安全ではなく、セキュリティ プロトコルを使用しないと誰でも傍受できるからです。
22. マイクロサービス アーキテクチャを作成するには、GraphQL が最適だと思いますか?
GraphQL はマイクロサービス アーキテクチャをクライアントから秘密にしておくため、マイクロサービスと GraphQL は完全に連携します。
フロントエンドからはすべてのデータを XNUMX つの API から取得し、バックエンドからはデータをマイクロサービスに分割する必要があります。 両方を達成するために私が知っている最善の手法は、GraphQL を使用することです。
バックエンドをマイクロサービスに分割しながら、各アプリケーションに単一の API を提供し、さまざまなサービスからのデータを結合できるようにします。
23.安全なHTTPメソッドとべき等HTTPメソッドの主な違いは何ですか?
べき等メソッドは、同じリクエストを通じて XNUMX 回または複数回呼び出されたときに、同じ結果を生成します。 PUT メソッドはべき等です。
すべての安全な方法はべき等ですが、安全な方法はリソースを変更しないため、すべてのべき等の方法が安全であるとは限りません。 たとえば、GET はデータを取得するだけでリソースを変更しないため安全です。
さらに、これはべき等です。つまり、呼び出されたときに常に同じ応答が返されます。
24. JAX-RS API は、RESTful ルート リソース クラスによって何を意味しますか?
Java Enterprise Edition は、JAX-RS API 要件に準拠するクラスとインターフェースを提供します。 JAX-RS の助けを借りて、REST アーキテクチャー・スタイルでの Java Web サービスの作成が容易になります。
JAX-RS API では、ルート リソース クラスは単なる「プレーン オールド Java オブジェクト」または POJO です。 必要な Web リソースを実装するために、JAX-RS アノテーションを採用しています。
@path 注釈があるか、少なくとも XNUMX つのメソッドに @path 注釈があります。 それらは、API エンドポイントを処理するためのメソッドを備えた Java クラスとして要約できます。
25. Postman とは正確には何ですか? なぜ使用されるのですか?
Postman という API 開発ツールを使用して、API の作成、テスト、および変更を行います。 このツールは、開発者が API に必要なあらゆる機能に使用できます。 開発者の作業を簡素化し、容易にします。
Postman を使用すると、GET、POST、PUT、PATCH などのさまざまな HTTP クエリを作成し、後で使用するために環境を保存し、API をさまざまな言語のコードに変換することが容易になります。
Postman を使用すると、API サイクルの各段階が簡素化され、連携が合理化されて API 開発が迅速化されます。
さらに、開発者はドキュメント、仕様、テスト ケース、プロセス、および API カタログを管理できます。
26. REST API はどのように安全に保たれていますか?
REST API は SOAP API ほど厳密なセキュリティ保護を使用しないため、REST API を使用して機密データを送信または取得しないでください。
ただし、信頼できる REST API は、安全で信頼できるデータ転送のためのセキュリティ コントロールを統合し続けています。
- 認証と認可: API に対して行われるすべてのリクエストは、これら XNUMX つのチェックに合格する必要があります。 認証を通じてクライアントの ID を検証することと、承認を通じて要求されたリソースにアクセスする権限があることを検証することは、XNUMX つの異なるプロセスです。
- 検証: API がそのリソースへのアクセスを許可する前に、認証と承認の後、リクエストをチェックして有害な可能性のあるコードがないか確認する必要があります。 したがって、サーバーはインジェクション攻撃に対して無防備になります。
- 検証: API がそのリソースへのアクセスを許可する前に、認証と承認の後、リクエストをチェックして有害な可能性のあるコードがないか確認する必要があります。 したがって、サーバーはインジェクション攻撃に対して無防備になります。
- 暗号化: TLS/SSL 暗号化は、クライアントとサーバー間の接続を保護し、ハッカーが要求と応答を傍受するのを防ぎます。
- 制限やスロットリングなどのレート制限技術は、サーバーを劣化またはクラッシュさせることを目的とした DDoS などのブルート フォース攻撃からサーバーを保護します。
- URI に機密情報を含めない: リソースの URI には、保護されたデータ (ユーザー名、パスワード、認証トークンなど) を含めないでください。
まとめ
おめでとう! いくつかの基本的なものから複雑なものまで、REST API 面接の質問とそれぞれの解決策がすぐにわかります。
いくつかの典型的な REST API インタビューの質問にどのように応答するかについて良い概念が得られたので、インタビューに応答することができます。 次のステップは、目的によって異なります。
訪問 インタビューシリーズ Hashdork と一緒にインタビューの準備をします。
コメントを残す