rest api response codes
このチュートリアルでは、さまざまなREST応答コード、RESTリクエストの種類、および従うべきいくつかのベストプラクティスについて学習します。 ：
前のチュートリアル、REST APIアーキテクチャと制約では、Webサービス、RESTアーキテクチャ、POSTMANなどについて学習しました。
詳細については、RESTAPIの最初のチュートリアルを参照してください。
検索エンジンで単語やフレーズを検索すると、検索エンジンはリクエストをウェブサーバーに送信します。 Webサーバーは、要求のステータスを示す3桁の応答コードを返します。
学習内容：
RestAPI応答コード
これは、POSTMANまたは任意のRESTAPIクライアントでRESTAPIテストを実行するときに通常表示される応答コードのサンプルです。
＃1）100シリーズ
これらは一時的な応答です
- 100続行
- 101スイッチングプロトコル
- 102処理
＃2）200シリーズ
クライアントはリクエストを受け入れ、サーバーで正常に処理されます。
JavaよりもC ++の方が優れています
- 200 – OK
- 201 –作成
- 202 –承認済み
- 203 –信頼できない情報
- 204 –コンテンツなし
- 205 –コンテンツのリセット
- 206 –部分的なコンテンツ
- 207 –マルチステータス
- 208 –すでに報告されています
- 226 –使用されるIM
＃3）300シリーズ
このシリーズに関連するコードのほとんどは、URLリダイレクト用です。
- 300 –複数の選択肢
- 301 –恒久的に移動
- 302 –見つかりました
- 303 –その他を確認
- 304 –変更なし
- 305 –プロキシを使用する
- 306 –スイッチプロキシ
- 307 –一時的なリダイレクト
- 308 –永続的なリダイレクト
＃4）400シリーズ
これらはクライアント側のエラーに固有です。
- 400不正な要求
- 401 –無許可
- 402 –支払いが必要
- 403禁止します
- 404お探しのページが見つかりませんでした
- 405 –メソッドは許可されていません
- 406 –受け入れられない
- 407 –プロキシ認証が必要
- 408 –リクエストタイムアウト
- 409 –競合
- 410 –なくなった
- 411 –必要な長さ
- 412 –前提条件が失敗しました
- 413 –ペイロードが大きすぎます
- 414 –URIが長すぎます
- 415 –サポートされていないメディアタイプ
- 416 –範囲が満足できない
- 417 –期待に失敗しました
- 418 –私はティーポットです
- 421 –誤ったリクエスト
- 422 –処理不可能なエンティティ
- 423 –ロック
- 424 –依存関係の失敗
- 426 –アップグレードが必要
- 428 –前提条件が必要
- 429 –リクエストが多すぎます
- 431 –リクエストヘッダーフィールドが大きすぎます
- 451 –法的な理由で利用できません
＃5）500シリーズ
これらはサーバー側のエラーに固有です。
- 500内部サーバーエラー
- 501 –実装されていません
- 502不正なゲートウェイ
- 503 –サービスを利用できません
- 504ゲートウェイのタイムアウト
- 505 –HTTPバージョンはサポートされていません
- 506 –バリアントもネゴシエートします
- 507 –不十分なストレージ
- 508 –ループが検出されました
- 510 –拡張されていません
- 511 –ネットワーク認証が必要
これとは別に、いくつかの異なるコードが存在しますが、それらは現在の議論から逸脱します。
さまざまなタイプのRESTリクエスト
ここでは、RESTAPIのすべてのメソッドとコレクションについて説明します。
| 方法 | 説明 |
|---|---|
| パッチ | putと非常によく似ていますが、リソースコンテンツのマイナーな操作に似ています |
| 取得する | ステータス行、応答本文、ヘッダーなどを取得します。 |
| 頭 | GETと同じですが、ステータス行とヘッダーセクションのみをフェッチします |
| 役職 | 主にサーバーでレコードを作成する際に、リクエストペイロードを使用してリクエストを実行します |
| プット | リクエストペイロードを使用してリソースを操作/更新するのに役立ちます |
| 削除 | ターゲットリソースに関連する情報を削除します。 |
| オプション | ターゲットリソースの通信オプションを説明する |
注意： POSTMANを使用して実行できるメソッドは多数存在しますが、POSTMANを使用して以下のメソッドについてのみ説明します。
ダミーのURLを使用してデモンストレーションします http://jsonplaceholder.typicode.com 。このURLは希望する応答を提供しますが、サーバーでの作成や変更はありません。
＃1）GET
リクエストパラメータ：
方法：GET
URIのリクエスト： http://jsonplaceholder.typicode.com/posts
クエリパラメータ：id = 3;
受信した応答：
応答ステータスコード：200 OK
xboxoneで動作するvr
レスポンスボディ ：
＃2）HEAD
リクエストパラメータ：
方法：HEAD
URIのリクエスト： http://jsonplaceholder.typicode.com/posts
＃3）投稿
＃4）PUT
＃5）オプション
リクエストパラメータ：
方法：オプション
URIのリクエスト： http://jsonplaceholder.typicode.com/
ヘッダー：Content-type = Application / JSON
＃6）パッチ
RESTAPIの検証中のベストプラクティス
＃1）CRUD操作
提供されている最低4つのメソッドで構成され、WebAPIで機能する必要があります。
GET、POST、PUT、およびDELETE。
＃2）エラー処理
エラーとそれが発生した理由に関するAPIコンシューマーへの可能なヒント。また、詳細レベルのエラーメッセージを提供する必要があります。
＃3）APIバージョニング
URLで文字「v」を使用してAPIバージョンを示します。 例えば-
http://restapi.com/api/v3/passed/319
URLの最後にある追加のパラメーター
http://restapi.com/api/user/invaiiduser?v=6.0
＃4）フィルタリング
ユーザーが指定できるようにするには、一度にすべてを提供するのではなく、目的のデータを選択します。
/ contact / sam？名前、年齢、指定、オフィス
/ contacts？limit = 25＆offset = 20
＃5）セキュリティ
すべてのAPIリクエストとレスポンスのタイムスタンプ。 access_tokenを使用して、APIが信頼関係者によって呼び出されていることを確認します。
実世界でのJavaのアプリケーション
＃6）分析
REST APIにAnalyticsを含めると、特にフェッチされるレコードの数が非常に多い場合に、テスト対象のAPIに関する優れた洞察が得られます。
＃7）ドキュメント
APIコンシューマーがそれを使用し、サービスを効果的に利用できるように、適切なドキュメントを提供する必要があります。
＃8）URL構造
URL構造はシンプルなままで、ユーザーはドメイン名を簡単に読み取れる必要があります。
例えば 、 https://api.testdomain.com。
Rest APIを介して実行される操作も、非常に理解しやすく、実行しやすいものでなければなりません。
たとえば、電子メールクライアントの場合：
取得する： read / inbox / messages –受信トレイの下にあるすべてのメッセージのリストを取得します
取得する： 読み取り/受信ボックス/メッセージ/ 10 –読み取り10th受信トレイのメッセージ
役職： create / inbox / folder –受信トレイの下に新しいフォルダを作成します
削除： 削除/スパム/メッセージ–スパムフォルダの下にあるすべてのメッセージを削除します
プット： folder / inbox / subfolder –受信トレイの下のサブフォルダーに関連する情報を更新します。
結論
多くの組織は、REST Web APIを実装することを好みます。これは、実装が非常に簡単で、従うべき標準とルールが少なく、アクセスが簡単で、軽量で、理解しやすいためです。 POSTMANは、ユーザーフレンドリーなUI、使いやすさとテストのしやすさ、応答速度の高速化、新しいRUNNER機能により、RESTfulAPIとともに使用すると利点があります。
このRestAPIチュートリアルシリーズの次のチュートリアルでは、手動で実行したテストケースを自動化します。