API は、 Application Programming Interfaceの略です。これは、アプリケーションが他のアプリケーションから一部のリソースにアクセスするためのゲートウェイとして機能します。
API を使用する利点は、サードパーティ アプリケーションへのアクセスを提供し、サードパーティ アプリケーションがアプリケーションのデータ全体にアクセスできないようにすることです。彼らは、API を通じて公開したデータにのみアクセスできます。
データにアクセスしたいアプリケーションまたはユーザーはクライアントと呼ばれ、データを提供するアプリケーションはサーバーと呼ばれます。
API は現在、あらゆるソフトウェア アーキテクチャで広く使用されています。フロントエンド、バックエンド、フルスタック、またはネットワーク エンジニアリングの役割に応募する場合、API に関する多くの質問を受けることになります。
そうは言っても、REST API に関して面接で最もよく聞かれる質問のいくつかを見てみましょう。
レストとは何ですか?
回答: REST は、API の動作に関するいくつかの制約を定義するアーキテクチャ設計です。 REST の原則に従った API は、RESTful API として知られています。 REST はRepresentational State Transferの略です。
これはプロトコルや標準ではありません。代わりに、さまざまな方法で API を実装するために使用できるアーキテクチャです。
開発者に高い柔軟性と自由度を提供するため、API の開発に広く使用されています。 REST アーキテクチャの原則の一部を次に示します。
- クライアントとサーバーの分離: RESTful API では、クライアントは、URI (Uniform Resource Identifier) を介してデータを要求する以外の方法でサーバーに影響を与えてはなりません。同様に、サーバーはクライアントのコンテンツをいかなる方法でも変更してはなりません。
- ステートレス性: 2 つの別々のリクエストが行われた場合、それらはお互いのことを知りません。言い換えれば、リクエストはステートレスであり、状態を維持しません。リクエストが満たされた場合、リクエストは単に終了します。すべてのリクエストは他のリクエストから分離されています。
- 階層化アーキテクチャ: クライアントまたはサーバーは、リクエストがオリジンに対して直接行われているのか、それとも中間アプリケーションに対して行われているのかを知りません。彼らは要求に対する応答だけを気にします。
- キャッシュ: データまたは応答をクライアント側とサーバー側でキャッシュして、パフォーマンスとスケーラビリティを向上させることができます。特定のリソースに対するリクエストが頻繁にある場合、そのリクエストに対する応答をキャッシュし、必要なときに使用できます。
REST の主な特徴は何ですか?
回答: REST の主な特性または機能は次のとおりです。
- 柔軟性: あるサーバーから別のサーバーに移動できますが、API は特定のリクエストに対して同じ応答を送信するため、何も変わりません。また、さまざまな種類のデータに対して必要なだけエンドポイントを追加できます。
- スケーラビリティ: キャッシュにより、応答が後で使用できるように保存されるため、スケーラビリティが向上します。これにより、サーバーの負荷が軽減され、待ち時間も短縮されます。
- Authorization : Authorization ヘッダーを使用して、サーバーがリクエストを承認するために使用できる資格情報を指定できます。
- ステートレス性: これは、リクエストが他のリクエストで何が起こっているかを知ることができないため、REST の最も重要な機能です。リクエストは分離され、満たされるとすぐに終了されます。
REST アーキテクチャのリソースとは何ですか?
回答: リソースは、取得、更新、削除などのさまざまな操作が実行されるエンティティです。これらは、REST アーキテクチャの基本的な構成要素です。
たとえば、オンラインの電子商取引ストアを考慮すると、製品、ユーザー、およびメタデータは操作できるため、リソースとみなされます。 API を介してリソースを別のアプリケーションに転送できます。
REST API の長所と短所について言及します。
回答: REST API の利点は次のとおりです。
- 実装は簡単です。
- リソースを簡単に扱うことができます。
- クライアントサーバーアーキテクチャのため、拡張性があります。
- XML や JSON などの複数のデータ転送メディア タイプをサポートします。
その欠点は次のとおりです。
- リクエスト間で状態を維持することはできません。
- 階層化されたアーキテクチャのため、リソースの本当の発信元を知ることはできません。
- 複雑なクエリやリクエストには適していません。
RESTテンプレートを定義します。
回答: REST テンプレートは、Spring フレームワークの REST API にアクセスできるユーティリティまたはクライアントです。基本的に、REST API からリソースをリクエストするために記述する必要がある定型コードを非表示にします。
RESTfulとは何ですか?
回答: RESTful API またはサービスは、REST ( Representational State Transfer ) アーキテクチャ スタイルを実装し、HTTP などのプロトコルを使用して動作するインターフェイスです。
RESTful Webサービスとは何ですか?
回答: RESTful Web サービスは、Web 上で最適に動作するように構築されています。 Representational State Transfer (REST) は、統一インターフェイス、階層化アーキテクチャ、ステートレス性などの制約を指定するアーキテクチャ スタイルで、Web サービスに適用すると、サービスが最適に動作するようにするパフォーマンスやスケーラビリティなどの望ましい特性が得られます。ウェブ。
RESTful Web サービスをテストするにはどうすればよいですか?
回答: RESTful Web サービスをテストするには、Postman や Thunder Client などの REST クライアントを使用して、テストする Web サービスをクエリします。そして、応答を受け取ったら、その応答を理解します。それが重要な部分です。
多くのエンドポイントを含む複雑な API をテストする場合は、テストを分割して、単体テスト、統合テスト、パフォーマンス テスト、およびエンドツーエンド テストを実行する必要がある場合があります。
RESTful Web サービスのいくつかの機能について言及します。
回答: RESTful Web サービスの主な機能の一部は次のとおりです。
- JSON や XML などの複数のメディア タイプのサポート。
- スケーラビリティ
- クライアントとサーバーの分離
- 柔軟性
RESTful ルート リソース クラスを定義します。
回答: ルート リソース クラスは、 @Path で注釈が付けられているか、 @Path で注釈が付けられた少なくとも 1 つのメソッドまたは@GET
、 @POST
、 @PUT
、 @DELETE
。
URIとは何ですか?
回答: URI は、Uniform Resource Identifier の略です。これは、API またはサービスのリソースを検索または識別するために使用される文字のシーケンスです。リソースの名前または場所を使用してリソースを識別しますが、特定の方法や技術には依存しません。
REST におけるステートレスとは何ですか?
回答: ステートレスとは、2 つのリクエストが相互に何が起こっているかを認識できない API に適用される 1 つの制約を指します。つまり、リクエストの状態は維持されません。リクエストが満たされた場合、レスポンスを取得した後に単純に終了します。
JAX-RSとは何ですか?
回答: JAX-RS は、REST アーキテクチャを使用する Java アプリケーションの開発を可能にする Java API です。この API を使用すると、Java での REST アプリケーションの開発が簡単になります。
JAX-RS API の主要なアノテーションとは何ですか?
回答: JAX-RS のアノテーションは、開発者が Java クラスを修飾してリソースと、それらのリソース上で実行できるメソッドを定義するために使用されます。 JAX-RS API の重要なアノテーションのいくつかは次のとおりです。
-
@GET
: HTTP で GET リクエストを行うために使用されます。 -
@POST
: HTTP で POST リクエストを行うために使用されます。 -
@Path
: Java クラスの相対パスを参照します。 -
@QueryParam
: URI または URL のクエリ パラメーターを指します。
JAX-RS API の主な機能は何ですか?
回答: JAX-RS の機能は次のとおりです。
- クライアント側のキャッシュ
- サーバー側のキャッシュ
- クエリ文字列のカスタマイズ
- 実行時の注釈
JAX-RS アプリケーションはどのように構成できますか?
回答: JAX-RS アプリケーションは、WAR ファイル内にパッケージ化された少なくとも 1 つのリソース クラスで構成されます。アプリケーションのリソースがリクエストに応答するベース URI は、次の 2 つの方法のいずれかで設定できます。
- WAR 内にパッケージ化された javax.ws.rs.core.Application のサブクラスで @ApplicationPath アノテーションを使用する
- WAR の web.xml デプロイメント記述子内での servlet-mapping タグの使用
JAX-WS および JAX-RS とは何ですか?
回答: JAX-WS は、XML ベースのメッセージング プロトコルである Simple Object Access Protocol (SOAP) を使用して API を開発するために使用される Jakarta XML Web サービス API です。
一方、JAX-RS は、REST アーキテクチャを使用して Web サービスを作成するために使用される Java API です。
HTTPステータスコードとは何ですか?
回答: ステータス コードは、サーバーからクライアントに送信された応答のステータスを伝える手段にすぎません。これらは、サーバーによって送信される応答ヘッダーに存在します。
クライアントは、ステータス コードを使用して、リクエストが失敗したか、完了したか、または応答に問題があるかどうかを判断できます。
HTTP の一般的なステータス コードをいくつか示します。
-
200
– 「OK」キーワードを表します。これは、リクエストが満たされ、応答に問題がないことを意味します。 -
404
– 「見つかりません」の略です。これは、サーバー上にリソースが存在しないか、エンドポイントが存在しないことを意味します。 -
500
– 「内部サーバー エラー」を表します。これは通常、サーバーが正しい応答を生成できない場合、または明示的にスローされていないエラーがある場合に発生します。 -
503
– 「サービス利用不可」を表します。これは、現在サーバーがリクエストを処理できないことを意味します。おそらくサーバーが停止しているか、リクエストの過負荷により機能していないためです。サーバーがメンテナンスのために稼働しているときにも発生する可能性があります。
HTTPメソッドとは何ですか?
回答: HTTP メソッドは、API の特定のリソースに対して特定のタイプのアクションを実行するために使用されます。たとえば、ムービー コレクション API からムービーのリストを取得する場合は、HTTP によって提供される GET メソッドを使用できます。データを更新する場合は、HTTP が提供する POST メソッドを使用できます。
よく使用される HTTP メソッドは次のとおりです。
- GET : GET を使用したリクエストはデータのみを取得する必要があります。
- POST : 新しく更新されたリソースをサーバーに送信することで、リソースを更新します。
- DELETE : 指定されたリソースを削除します。
- PATCH : リソースを部分的に変更します。
HTTP 基本認証はどのように機能しますか?
回答: 認証は、データのセキュリティを維持するためにクライアントの信頼性を検証するプロセスです。 HTTP では、クライアントによって送信される認証ヘッダーを介して認証が行われます。
認可ヘッダーはクライアントのユーザー名/ID とパスワードで構成され、サーバーによって検証されてアクセスが許可されます。
ここで注意すべき重要な点は、HTTP 認証を使用する場合、資格情報が通過するチャネルは暗号化され、安全である必要があるということです。
HTTPS に統合されている SSL 層を使用してチャネルを保護できます。したがって、資格情報を扱うときは、単純な HTTP ではなく HTTPS を使用することをお勧めします。
HTTP リクエストのコアコンポーネントは何ですか?
回答: HTTP リクエストは次のコンポーネントで構成されます。
- リクエスト行: これはリクエストの最初の行で、HTTP メソッド、パスまたはエンドポイント、HTTP バージョン番号で構成されます。
- ヘッダー: HTTP ヘッダーは、リクエストのメタデータを提供するために使用されます。
- Body (オプション) : このコンポーネントは、一部のリクエスト メソッドにのみ存在します。 GET リクエストには必要ありませんが、POST リクエストには必要です。これはリクエストの実際のメッセージです。
HTTP 応答のコアコンポーネントは何ですか?
回答: HTTP 応答は次のコンポーネントで構成されます。
- ステータス: サーバーによって送信される HTTP ステータス コードを指します。
- ヘッダー: リクエストと同様に、レスポンスにもそれぞれのヘッダーがあり、レスポンスに関する有用な情報が提供されます。
- メッセージ: これは、特定のリソースを要求するためにサーバーからクライアントに送信される実際のデータです。
REST と AJAX の違いは何ですか?
回答: AJAX は、RESTful API にアクセスできるクライアントです。 JavaScript を使用して非同期リクエストを送信するために使用されます。
REST (Representational State Transfer) は、RESTful API を作成するために実装できるアーキテクチャです。つまり、HTTP リクエストを送信するには、クライアントとして機能する AJAX を使用できますが、RESTful API を実装したい場合は、REST アーキテクチャを使用する必要があります。
SOAPとRESTの違いは何ですか?
回答: Representational State Transfer (REST) は、 API を作成するための制約が最小限に抑えられたアーキテクチャです。 SOAP ( Simple Object Access Protocol) は、 API を実装するための厳格な要件を持つプロトコルです。
REST は SOAP よりも柔軟で使いやすいです。 SOAP では XML ベースのメッセージングが使用されますが、REST では、JSON、XML などの多くのデータ転送タイプを使用できます。SOAP と比較して、REST は軽量で高速です。
SOAP Web サービスにはセキュリティが組み込まれており、これが REST よりも SOAP を使用する利点の 1 つですが、追加された機能により、使用が複雑で重くなります。
PUT と POST の違いは何ですか?
回答: POST は、サーバーにデータを送信する HTTP リクエスト メソッドです。特定のリソースに対して複数の POST リクエストを行うと、データに副作用が生じる可能性があります。たとえば、コレクションに記事を追加する場合、複数の POST リクエストを行うと、複数の記事がコレクションに追加され、記事が冗長になります。
PUT は、特定のリソースのデータをサーバーに送信する HTTP リクエスト メソッドですが、データの更新は 1 回だけです。特定のリソースに対して複数の PUT リクエストを送信しても、副作用は発生せず、データは 1 回だけ追加されます。 PUT では、リソースが存在しない場合は新しいリソースが作成され、存在する場合は既存のリソースが更新されます。
PUT は冪等ですが、POST は冪等ではありません。
ペイロードとは何ですか?
回答: REST API のペイロードは、クライアントからサーバーに送信されるリクエストの本文にすぎません。これはサーバーに送信して応答を受け取りたいデータです。
Post メソッドで送信できる最大ペイロード サイズはどれくらいですか?
回答: HTTP プロトコル自体によって設定されるデフォルトの制限はありません。この制限は、クライアントまたはサーバーの最小値の上限に依存します。
URI を作成する際に従う必要があるベスト プラクティスは何ですか?
回答: URI を設計する際に留意する必要がある重要な点は次のとおりです。
- ファイル拡張子の使用を避ける
- すべての URI と一貫性を持たせる
- URI をさまざまなリソースのセットのドメインとサブドメインに分割します。
- URI に埋め込まれた文内の単語を区切るには、ハイフンまたはアンダースコアを使用する必要があります。
- リソースの階層を示すにはスラッシュを使用する必要があります。
- 適切なエンコードを使用して URI をエンコードする
- URI を人間が判読できるようにしてください
冪等メソッドとは何ですか?
回答: 冪等 HTTP メソッドは、同一のリクエストを複数送信しても、サーバーに対して同じ効果をもたらします。たとえば、特定のリソースに対して複数の同一の DELETE リクエストを送信した場合、リソースはリクエストごとに変更されるわけではありません。リクエストが 1 つだけ送信されたかのように更新されます。
冪等メソッドには次のようなものがあります。
- 置く
- 消去
- 得る
- 頭
- オプション
ポストマンとは何ですか?
回答: Postman は、API を開発、変更、テストするための API 開発ツールです。クライアントをセットアップする必要がなく、API を迅速に構築およびテストするための多くの機能が提供されます。
キャッシュ制御ヘッダーとは何ですか?
回答: Cache-Control ヘッダーは、ブラウザーとサーバーでキャッシュを構成するための命令またはディレクティブで構成されます。これは、ブラウザまたはサーバーに、何をキャッシュするか、およびネットワーク要求を通じて要求される前にどれくらいの期間キャッシュする必要があるかを指示します。
Cache-Control ヘッダーには次のディレクティブが含まれています。
- 最大年齢
- キャッシュなし
- プライベート
- 公共
- 無店舗
- 不変
RESTful Web サービスでのメッセージングを定義します。
回答: RESTful Web サービスのメッセージングとは、クライアントが HTTP リクエストをサーバーに送信し、サーバーが HTTP レスポンスで応答することを指します。クライアントとサーバー間のこの通信は、メッセージングと呼ばれます。
モノリシック、SOA、マイクロサービス アーキテクチャの違いは何ですか?
回答: モノリシック アーキテクチャでは、すべてが 1 か所で管理されます。クライアント側、サーバー、データベースはすべて 1 か所から管理されます。 「モノリス」という言葉が単一のブロックまたは石を指すため、それがモノリシックとして知られるのはそのためです。
SOA はサービス指向アーキテクチャの略です。このアーキテクチャでは、アプリケーションのさまざまな側面が、同じくソフトウェアであるさまざまなサービスによって管理されます。つまり、複数のサービス ソフトウェア モジュールを組み合わせたものになります。統合はこのアーキテクチャの重要な部分です。
マイクロサービス アーキテクチャは SOA に似ていますが、SOA とは異なり、API を使用して相互に通信する複数の自律的なソフトウェア プログラムを備えています。モノリシックなアーキテクチャとは異なり、ここではすべてが自律的であり、ある程度独立しています。
マイクロサービス アーキテクチャはどのように機能するのでしょうか?
回答: マイクロサービス アーキテクチャでは、アプリケーションは互いに独立して独自に動作する小さなサブユニットに分割されますが、明確に定義された API セットを介して相互に通信します。
マイクロサービス アーキテクチャの利点には、俊敏性、柔軟性、拡張性、独立したテクノロジ、再利用可能なサービス、簡単な展開などがあります。
CRUDとは何ですか?
回答: CRUD は、作成、読み取り、更新、削除の略です。これらは、特定のリソースに対して実行できる操作です。これらすべての操作をサポートする API は CRUD API として知られています。これらは、リソースに対して API によって実行できる最も基本的な操作です。
キャッシングとは何ですか?
回答: キャッシュとは、後で再度使用できるように、クライアントまたはサーバーに応答またはリクエストを保存する技術です。
クライアントが短期間に同じリクエストを数回行う場合、ネットワーク経由で再度レスポンスをリクエストして帯域幅を無駄にすることは意味がないため、レスポンスは通常クライアント上にキャッシュされます。
@RequestMapping の用途は何ですか?
回答: これは、Web リクエストを特定のハンドラー クラスやハンドラー メソッドにマップするために使用される Spring フレームワークのアノテーションです。
@PathVariable は何をしますか?
回答: Spring フレームワークの @PathVariable アノテーションは、テンプレート変数の値を抽出し、その値をメソッド変数に割り当てるために使用されます。
HttpMessageConverter を定義します。
回答: HTTP リクエスト (またはその一部) をハンドラー メソッドの引数として必要な型に変換する必要がある場合、またはハンドラー メソッドによって返された値を何らかの方法で変換して HTTP 応答を作成する必要がある場合、HTTPメッセージコンバータが使用されます。
Web API をテストするにはどのようなツールが必要ですか?
回答: API テストに役立ついくつかのツールは次のとおりです。
- 郵便屋さん
- 安心してください
- レストシャープ
- カタロン
- ReadyAPI
- アピジー
最後の言葉
現在、インターネットの出現により、API は非常に普及しています。 REST API が人気があるもう 1 つの理由は、開発が簡単で使いやすいことです。
面接の準備をしている場合は、面接で尋ねられる可能性のある REST API に関する上記の質問を検討してください。
次に、 の Web スクレイピング API を使用して Web サイトをスクレイピングする方法を確認できます。