クラウド コンピューティングやマイクロサービス ベースのアーキテクチャを含むいくつかの開発は、RESTful APIによって可能になりました。彼らは、オンライン コミュニケーションとコンピューティングをシンプルなものとして描いてきました。したがって、すべての開発者は、 REST とは何か、REST がどのように機能するか、その利点、および時代に遅れずについていくための安全なサービスを作成する方法を理解する必要があります。彼らは、スケーラブルで保守が簡単なソリューションの作成を支援し、インターネットの力のおかげで製品を世界中に届けることができるため、多くの企業は REST を理解している開発者を好みます。
RESTful API 関連の面接の質問に備えるにはどうすればよいですか?
REST API インタビュー中に RESTful Web サービスに関する最も頻繁な REST API インタビューの質問、および Spring MVC フレームワークを使用して構築された JAX-RS ライブラリーおよび RESTful Web サービスに関する問い合わせは、以下のセクションに記載されています。面接に参加したり、面接のスケジュールを設定したりする前に、言及されているすべての REST API 面接の質問に備えることが重要です。
レストとは？
Representational State Transfer を説明する REST は、HTTP プロトコルで確立された Web サイト アプリの開発を担当します。 REST は、Web サイト関連の有用性がそれを信じるために付加しなければならないいくつかのルールを指定します。この提案により、サーバーとユーザーの間で標準化された HTTP メソッドが送信を仮想的に送信することが保証されます。
REST API とは何ですか?
RESTful API は、2 つのコンピューター システム間で安全なオンライン情報交換を行います。さまざまなアクティビティを完了するために、 ビジネス アプリケーションの大部分は、他の内部および外部プログラムとデータを交換します。たとえば、内部の会計システムが従業員情報を外部の銀行システムと共有して給与明細を生成する場合などです。この情報は個人的なものであり、REST API ソフトウェア標準は安全で効率的で信頼できるものであるため、REST API を使用して実行できます。
RESTful API は、何らかの方法で REST にリンクされている API として知られています。すべてのデータは REST API のリソースと見なされ、(URI) と呼ばれる正確な標準定数単位によって決定されます。 Twitter API は、ユーザーがアクセスして取得できるリソースとしてツイートを作成します。 Twitter API を使用すると、ユーザーは簡単にツイートを投稿できます。
REST の原則は何ですか?
クライアントサーバーでは、コンシューマーとサーバーの間で送信するために使用される一連の応答が可能です。どちらも相互に応答を送受信できます。このクライアント サーバー方式の明確なビジョンにより、両方の勢力が相互に支援を受けずに活動できるようになります。
レイヤードシステム
クライアントと API サーバーの間のレイヤーはサーバーです。これらの異なるサーバーは、スパムの検出やパフォーマンスの向上など、いくつかのタスクを実行します。クライアントとアプリケーション プログラミング インターフェイス (API) サーバーの間で送信されるメッセージは、レイヤーを追加または削除しても影響を受けません。これは、REST (representational state) がモジュラー アーキテクチャを使用しているためです。
統一インターフェース
クライアントとサーバーは、すべての通信に常に同じプロトコルを使用する必要があります。このプロトコルは HTTP REST です。すべてのアプリケーションが同じ言語を使用してデータを要求および提供するため、統一されたインターフェースによって統合が容易になります。
ステートレス
ステートレス通信では、サーバーは送信済みの応答の記録を保持しません。すべての応答には、取引を完了するために必要な完全な入力が含まれています。サーバーの負荷とメモリ使用量を減らすことで解釈を改善します。また、情報が不完全であるためにリクエストが失敗する可能性を排除します。
キャッシュ可能
クライアントは、リソースがキャッシュ可能かどうかを示すサーバーからのサーバー応答を使用して、任意のリソースをキャッシュしてパフォーマンスを向上させることができます。 REST には、次のオプションの条件も含まれています。
コードオンデマンド
API の応答には、ユーザーが実行できる実行可能コードを含めることができます。したがって、クライアント アプリケーションは独自のバックエンドでコードを実行できます。
AJAX と REST の違いは何ですか?
AJAX と REST の違いは次のとおりです。
| AJAX | 休み |
| XMLHttpRequest オブジェクトは、サーバーに要求を送信するために Ajax で使用されます。ただし、 JavaScriptのコードは、現在のページを動的に変更するための答えを提供します。 | リソースの使用率は、URI 構造と要求/応答パターンにとって重要です。 REST によって使用されます。 |
| Ajax は、ページをリロードせずにユーザー インターフェイスを動的に更新できるテクノロジのグループです。 | ユーザーは、REST ソフトウェア アーキテクチャ スタイルを使用して、サーバーからデータまたは情報を要求できます。 |
| Ajax は、サーバーとユーザーの間の非同期通信を排除します。 | REST は、サーバーとユーザー間の通信を要求します。 |
マイクロサービス アーキテクチャはどのように機能しますか?
クラウド アプリケーションを開発するためのアーキテクチャ手法は、マイクロサービスと呼ばれます。各アプリケーションは多数のサービスで構成されており、各サービスは個別のプロセスで実行され、API を介して他のサービスと対話します。 「マイクロサービス アーキテクチャ」として知られるアプリケーションの作成方法は、時間の経過とともにベスト プラクティスになりました。マイクロサービス アーキテクチャのコンポーネントは、ビジネスのニーズに基づいています。
- クライアント
リクエストは、さまざまなデバイスを使用して多数のユーザーから送信されます。
- ID プロバイダー
ユーザーまたは顧客の身元を確認し、セキュリティ トークンを提供します。
- API ゲートウェイ
クライアント リクエストは API Gateway 経由で処理されます。
- 静的コンテンツ
システムのすべての素材は、静的コンテンツに含まれています。
- 管理
障害を特定し、ノード間でサービスのバランスをとります。
- サービス発見
マイクロサービス間の通信経路を決定するためのツール。
- コンテンツ配信ネットワーク
プロキシ サーバーと関連するデータ センターの分散ネットワーク。
- リモートサービス
IT デバイスのネットワークに保存されている情報は、リモート サービスを利用してリモートからアクセスできます。
REST でサポートされている HTTP メソッドは何ですか?
REST HTTP でサポートされているメソッドは次のとおりです。
- GET - Web サイトや API で最も広く使用されているメソッドで、GET は特定のデータ サーバーからリソースを受け取ります。
- POST - POST メソッドを介して、データが API サーバーに送信され、リソースが更新されます。サーバーがデータを受信すると、それを HTTP 要求本文に格納します。
- PUT - リソースを作成および更新するためにデータを API に送信します。
- DELETE - 名前が示すように、このメソッドは特定の URL のリソースを削除するために使用されます。
- OPTIONS - サポートされている手法について詳しく説明します。
HEAD - リクエスト URL に関するメタデータが返されます。単一のレコードの観点から状況を調べてみましょう。従業員番号 1 の従業員のレコードがあるとします。次のアクティビティはそれぞれ異なることを示します。
POST - すでに作成されている従業員 1 の情報を取得しているため、これは適用されません。
GET - これは、RESTful Web API を介して従業員の情報を取得するために使用され、従業員番号は 1 になります。
PUT - RESTful Web API を使用して、従業員番号 1 を反映するように従業員の情報を更新するために PUT が使用されます。
DELETE - この関数は、従業員番号 1 の従業員の情報を削除するために使用されます。
PUT と POST の違いは何ですか?
PUT と Post の違いは次のとおりです。
- PUT - 提供された (Uniform Resource Identifier) URI でファイルまたはリソースを正確かつ具体的に識別します。 PUT は、既存のファイルがそのユニフォーム リソース識別子 (URI) に存在する場合、それを変更します。 PUT は、既にファイルが存在する場合はファイルを形成します。さらに、PUT は冪等性があり、ファイルの使用頻度にはまだ影響しないことを示唆しています。
- POST - 個別の統一リソース識別子 (URI) にデータを送信し、そこにあるリソース ファイルが要求を管理することを期待します。この時点で、Web サイト サーバーは、選択されたファイルのコンテキストでデータを使用して何ができるかを決定できます。さらに、POST 戦略はべき等ではありません。つまり、2 回以上使用すると、新しいファイルの生成が再開されます。
モノリシック SOA とマイクロサービス アーキテクチャの違いは何ですか?
モノリシックアプリは、開発速度が非常に遅く、相互接続された分割できないユニットで構成されています。小規模で最小限に接続されたサービスが SOA を構成しますが、これも開発が制限されています。
マイクロサービスは、非常に小さく、疎に接続されたスタンドアロン サービスであり、反復的な開発サイクルが迅速です。
URIとは？
Uniform resource identifier は URI と呼ばれます。 REST の URI は、Web サーバーのリソースを指定する文字列です。各リソースには個別の URI があり、HTTP 要求で使用されると、クライアントはそれをターゲットにしてアクションを実行できます。アドレッシングは、URI を使用してリソースにトラフィックを送信するプロセスです。
URI の形式は次のとおりです。
<プロトコル>://<サービス名>/<リソースタイプ>/<リソースID>
URIには2つのタイプがあります
1. URL - その場所からのリソースの取得に関する情報は、Uniform Resource Locator で入手できます。
URL には、ネットワークのホスト名 (sampleServer.com) とコンテンツへのパス (/samplePage.html) に関する情報が含まれており、プロトコル (FTP、HTTP など) で始まります。また、検索条件を指定することもできます。
2. URN - 独特で耐久性のある名前を使用することにより、統一されたリソース名がリソースを識別します。
インターネット上のリソースの場所は、必ずしも URN によって指定されるわけではありません。これらは、リソースを識別するときに使用する他のパーサーのモデルとして機能します。
URN がドキュメントを識別するたびに、「リゾルバー」を使用してすばやく URL に変換し、ダウンロードできるようにします。
RESTful Web サービスの機能は何ですか?
これらの機能は、すべての RESTful Web サービスに存在します。
- クライアント サーバー通信モデルは、サービスの基盤です。
- このサービスは、HTTP プロトコルを使用して、データ/リソースのフェッチ、クエリの実行、およびその他のタスクを実行します。
- 「メッセージング」は、クライアントとサーバー間の通信に使用される方法です。
- サービスは、URI を使用してリソースにアクセスできます。
- これは、クライアントの要求と応答が他に依存しないというステートレスの考え方に準拠しているため、必要なデータが取得されるという完全な確実性を提供します。
- 同じタイプの繰り返し要求に対するサーバー呼び出しを減らすために、これらのサービスはキャッシングの考え方も採用しています。
- これらのサービスは、SOAP サービスを使用して REST アーキテクチャ パターンを実装することもできます。
HTTP ステータス コードとは何ですか?
HTTP ステータスで使用される標準コードは、確立されたサーバー タスクの完了ステータスに対応しています。たとえば、HTTP ステータス 404 は、要求されたリソースがサーバーにないことを示します。
HTTP ステータス コードを見て、その意味を理解しましょう。
- 200 - OK、成功は明らかです。
- 201 - POST または PUT リクエストがリソースを正常に作成すると、応答コードは 201 - CREATED になります。 location ヘッダーを使用して、新しく生成されたリソースに URL を返します。
- 304 - 条件付き GET リクエストの場合、ネットワーク帯域幅を節約するためにステータス コード 304 NOT MODIFIED が使用されます。応答本文は無効でなければなりません。日付、場所、およびその他の情報は、ヘッダーに含める必要があります。
- 400 - BAD REQUEST は、データの欠落や検証ミスなどの無効な入力が提供されたことを示します。
- 401 - FORBIDDEN は、管理者権限なしでアクセスを削除するなど、使用されているメソッドにユーザーがアクセスできないことを示します。
- 404 - ERROR は、要求されたメソッドが見つからないことを示します。
- 409 - CONFLICTS メソッドが実行されると、重複するエントリの挿入など、競合する問題があることを示します。
- 500 - INTERNAL SERVER ERROR コードは、メソッドの実行中にサーバーが例外をスローしたことを示します。
RESTful Web サービスの欠点を教えてください。
RESTful Web サービスの欠点は次のとおりです。
- アシスタントはステートレスの概念に固執するため、RESTful Web サービスのセッションを維持することはできません。
- セキュリティと保護の制限は、REST にとって必須ではありません。一部のプロトコルは、安全保護のために使用されます。これを行うと、SSL/TLS 認証など、選択する保護および安全基準を決定する際に使用できる警告が表示されます。
SOAP と REST を区別しますか?
SOAP と REST の違いは次のとおりです。
| 石鹸 | 休み |
| SOAP と呼ばれるプロトコルを使用して Web サービスを実装します。 | REST は、Web サービスを開発するためのアーキテクチャー設計パターンです |
| SOAP が提供するガイドラインは、厳密に遵守することを目的としています。 | REST は基準の概要を示していますが、完全に準拠する必要はありません。 |
| SOAP クライアントとサーバーはより密接に関連しているため、この点で厳密な契約を持つデスクトップ プログラムに匹敵します。 | REST クライアントはブラウザより適応性が高く、必要な通信標準に準拠している限り、サーバーの設計に依存しません。 |
| クライアントとサーバー間の XML 転送のみが SOAP でサポートされています。 | XML、JSON、MIME、Text などの複数のデータ型が REST によって提供されます。 |
| SOAP 読み取りはキャッシュできません | REST 読み取りクエリはキャッシュ可能 |
| サービス インターフェイスは、リソース ロジックを公開するために SOAP によって使用されます。 | リソース ロジックは、URI を使用して REST を使用して公開されます |
| SOAP が遅い | REST の方が速い |
| プロトコルであるため、SOAP は独自のセキュリティ プロトコルを確立します。 | REST は、実装プロトコルに基づいたセキュリティ対策のみを行います |
| SOAP は頻繁に選択されるわけではありませんが、ステートフルなデータ転送とより高い信頼性が必要な場合に使用されます | 最近では、スケーラビリティと保守性が向上するため、REST が開発者に好まれることがよくあります。 |
HTTP レスポンスのコア コンポーネントを構成するものは何ですか?
HTTP 応答には、次の 4 つの主要なコンポーネントがあります。
- 応答ステータス コード - リソース リクエストに対するサーバーのステータス コードが表示されます。例: クライアント側のエラーは 400 で表され、成功した回答は 200 で表されます。
- HTTP バージョン - HTTP プロトコルのバージョンは、HTTP バージョンによって示されます。
- 応答ヘッダー - 応答メッセージのメタデータは、このセクションに含まれています。データは、コンテンツの長さ、種類、応答日、サーバーの種類などを提供するために使用できます。
- 応答本文 - サーバーが実際に返したリソースまたはメッセージは、応答本文に含まれています。
WebSocket と REST の違いは何ですか?
以下に、 WebSocketと REST の違いをいくつか示します。
REST は CRUD 操作に基づいていますが、WebSocket は基本的なトランスポート メカニズムであるソケットとポートの概念に基づいた低レベルのプロトコルです。
RESTful アプリケーションは、動詞と HTTP に基づいて操作を設計する必要がありますが、WebSocket では、アプリケーションの下位レベルの詳細である IP アドレスとポート情報を使用する必要があります。 WebSocket はステートフル プロトコルですが、REST はステートレス プロトコル上に構築されています。つまり、クライアントもサーバーもお互いを認識する必要はありません。
水平方向にスケーリングできる HTTP に基づく REST とは対照的に、WebSocket 接続は単一サーバー上で垂直方向にスケーリングできます。 REST ベースの通信は比較的高価ですが、WebSocket 通信は安価です。
REST にトランスポート層セキュリティ (TLS) を実装できますか?
はい、できます！ REST でのクライアント/サーバー間の通信は TLS を使用して暗号化されます。これにより、サーバーを確認する機能もユーザーに提供されます。これは Secure Socket Layer (SSL) に取って代わるため、ユーザーとサーバー間の安全な通信の形式です。 HTTPS は Secure Socket Layer (SSL) および Transport Layer Security (TLS) とうまく機能するため、RESTful Web サービスを作成するときに役立ちます。ここで、REST が使用するプロトコルの側面に関係していることに注意することが重要です。したがって、安全保護は REST のプロトコルに依存しています。
POST メソッドで送信できるペイロードの最大サイズは?
ポスト方式で運べるペイロードの大きさは理論上無制限です。ただし、ペイロードが大きいほど帯域幅を消費し、処理に時間がかかり、サーバーの応答性に影響することに注意してください。
JAX-RS API に存在する主要な注釈を一覧表示する
- パス - これは、REST リソースの相対 URI (Uniform Resource Identifier) パスの詳細を示します。
- GET - リクエスト メソッドのこの指定子は、HTTP GET に対応します。 GET クエリを処理します。
- POST - リクエスト メソッドのこの指定子は、HTTP POST に対応します。彼らは POST 問い合わせに対処します。
- PUT - リクエスト メソッドのこの指示子は、HTTP PUT リクエストに対応します。彼らはPUTの問い合わせを扱います。
- DELETE - HTTP DELETE に使用されるリクエスト メソッドの指定子として定義されます。これらは DELETE 要求を処理します。
- HEAD - リクエスト メソッドのこの指定子は、HTTP HEAD に対応します。彼らはHEADの問い合わせに対処します。
- PathParam - 開発者は、この URI (Uniform Resource Identifier) パス パラメーターを使用して、リソース クラス/メソッドの URI からパラメーターを抽出できます。
- QueryParam - リソース クラス/メソッドは、開発者がこの URI (Uniform Resource Identifier) クエリ パラメーターを使用して URI (Uniform Resource Identifier) から抽出したこれらのクエリを使用できます。
- プロデュース - 作成され、ユーザーに返信として送信される MIME リソース プレゼンテーションがここで指定されます。
- 消費 - これは、サーバーがユーザーからそれらを受け取るときに受け入れるか使用する MIME リソース プレゼンテーションの詳細を示します。
Spring で RestTemplate を定義する
ユーザーが RESTful サービスにアクセスするための主要なクラスは、RestTemplate と呼ばれます。 REST制限を利用して、サーバーとの通信を行います。これは、JdbcTemplate や HibernateTemplate など、Spring が提供するさまざまなテンプレート セクションに相当します。 RestTemplate はメソッドに (Uniform Resource Identifier ) URI テンプレート、URI (Uniform Resource Identifier) パス パラメータ、要求/応答の種類、要求オブジェクトなどを使用して通信する機能を提供します。GET などの HTTP メソッドの高レベルの実装の詳細を提供します。 、POST、PUT など。
Spring 4.3 のこのセクションでは、@GetMapping、PutMapping、@PostMapping などのよく使用されるアノテーションを提供します。その前に、Spring は @RequestMapping 解釈を提供して、使用されるメソッドを指定します。
@RequestMapping の用途は何ですか?
- リクエストは、アノテーションを使用して特定のハンドラ メソッドにマップされます。
- Dispatcher Servlet は、Spring ですべての受信 Web アプリケーション ルーティングを管理します。リクエストハンドラーを使用することで、リクエストを受信したときにリクエストを処理するコントローラーを決定します。 @Controller アノテーションを持つすべてのクラスは、Dispatcher Servlet によってスキャンされます。
コントローラーのメソッドとクラス内で定義される @RequestMapping アノテーションは、リクエスト ルーティング プロセスに不可欠です。
Web API を開発またはテストするためのツールまたは API を列挙する
Postman、Swagger などのさまざまなツールを使用して、RESTful Web サービスをテストできます。 Postman には、エンドポイントに要求を送信する機能、JSON または XML に変換できる応答を表示する機能、ヘッダーやクエリ パラメーターなどの要求パラメーターや応答ヘッダーを分析する機能など、多くの機能があります。 Postman と同様に、Swagger は多数の機能とエンドポイントを文書化する機能を提供します。 Jmeter などのツールを使用して、API のパフォーマンスと負荷をテストすることもできます。
キャッシングとは？
サーバー応答がキャッシュされると、同じ応答を再度生成する代わりに、必要に応じて新しいコピーを利用できるように保存されます。この手法は、サーバーの負担を軽減するだけでなく、パフォーマンスとスケーラビリティも向上させます。応答は、クライアントによってのみ、短時間だけキャッシュできます。
リソースのヘッダーと簡潔な説明が以下に含まれているため、キャッシング手順でそれらを識別できます。
- リソースが作成された日時
- 通常、最新の情報を保持するリソース更新の日時
- キャッシュ制御のヘッダー
- キャッシュされたリソースが動作を停止する日時
- リソースがフェッチされたときの開始点を確立する年齢
REST API を学ぶのに最適なリソースは何ですか?
Web サイトやモバイル アプリケーションを開発するための REST API を学習するための利用可能なリソースが多数あります。上位5位は以下の通り。
RESTful Web サービス
API を使用するアプリケーションの開発を開始するには、Leonard Richardson による RESTful Web Services wonder と呼ばれるこのガイドブックが、この点で非常に役立ちます。特に初心者で、Representational State Transfer (REST) Web サイト サービスの基本を理解したい場合。このリソースは、Representational State Transfer (REST) がどのように機能するか、および他の複数の重要な Web 関連サービスを例とともに明らかにしました。これは特定のプログラミング言語に基づいているわけではないため、RESTful API の理解はどのプログラミング言語にも限定されません。
REST API チュートリアル
REST API チュートリアルは、本や読書家でない場合に Representational State Transfer (REST) を学習するための優れたオンライン リソースです。このリソースは、REST を最初から最後まで学習するのに役立ち、すべての基本的な側面をカバーしています。このチュートリアルは、Representational State Transfer (REST) の紹介から始まり、HTTP 関連の戦略と知識などに関する例のパスをたどります。
REST API 設計ルールブック
これは、Representational State Transfer (REST) ガイダンスの優れたリソース ブックでもあります。本の著者である Mark Masse は、REST API を使用してアプリケーションを構築するのに役立った経験と戦略を伝えています。このリソースでは、アプリケーション URI を考案するためのプラクティス、HTTP ヘッダーを介してメタデータを送信するためのアプローチ、および使用できるメディアの種類について説明しました。さらに、HTTP の送信メソッドと応答ステータス コードの設計にどのように革新を加えるか。
API デベロッパー ウィークリー ニュースレター
API デベロッパー ウィークリー ニュースレターという素晴らしいリソースがあります。 Web ベースのアプリケーションとモバイル アプリの API 技術、構造、拡張、およびアーキテクチャに非常に集中しているため、RESTful API を学習するための最新のリソースです。このニュースレターは、開発者、プロジェクト マネージャー、アーキテクト向けに特別に作成されています。
安心してください
これは、Java と呼ばれる 1 つのプログラミング言語の経験がある人にとっては幸運な、オープンソースの REST テスト メディアです。このリソースは、RESTful API プロセスのテストと検証の手順を容易にします。また、REST-Assured は、複雑な反応をテストするためのボイラープレート コードを作成する必要性を根絶し、BDD 構文を支援します。
手短に
結論として、上記の記事では REST API インタビューの質問を共有しています。 RESTful API の知識を必要とする同様の仕事に応募しようとしている、または応募したことがある人のための REST API 面接の質問をすべてカバーしています。これらは、面接で面接官があなたに尋ねることができる最も一般的な質問です。また、最終面接を受ける前に、前述のリソースを確認してください。
さらに、Web サイト アプリケーションまたはモバイル アプリを構築する場合は、AppMaster が最終的な選択肢になります。これは、コーディングの経験や知識がなくても、ドラッグ アンド ドロップで簡単にあらゆる種類のアプリケーションを構築できるノーコード プラットフォームです。今日のお得な情報をチェックしてください。
