REST の概要。パート 2: クライアントとサーバー間の通信

パート 1: REST とは何ですか このパートでは、クライアントとサーバーの間で通信がどのように行われるかを詳しく見ていきます。その過程で、新しい用語を明らかにし、それらについて説明します。 すべてを明確にするために、RESTful アプリケーションの例を使用してクライアントとサーバーの通信を分析します。顧客とその注文に関する情報を保存できる Web アプリケーションを開発しているとします。それらの。私たちのシステムは、エンティティの作成、編集、削除、エンティティに関する情報の提供など、いくつかのエンティティを操作することができます。これらのエンティティは次のようになります。

• クライアント - クライアント。
• 注文 - 顧客の注文。
• アイテム - 商品。

REST アーキテクチャでは、クライアントはデータを取得または変更するためにサーバーにリクエストを送信し、サーバーはそのリクエストに対する応答をクライアントに送信します。

リクエスト

クライアントのリクエストは、ほとんどの場合 HTTP 経由で行われます。一般に、HTTP リクエストはいくつかのコンポーネントで構成されます。

• HTTP メソッド。
• タイトル;
• URI;
• リクエスト本文。

以下では、各構成要素について詳しく見ていきます。

URIとリソース

クライアントがリクエストを通じて取得または変更するデータはリソースと呼ばれます。クライアントとサーバーの対話の基礎はリソースの操作です。 REST のリソースは、名前を付けることができるものすべてです。ある意味、これらは Java のクラスに似ています。Java では、あらゆるもののクラスを作成できます。REST でも同じです。リソースは、ユーザー、ドキュメント、レポート、注文など、何でも構いません。これらすべては、何らかのエンティティの抽象化である場合もあれば、画像、ビデオ、アニメーション、PDF ファイルなどの具体的なものである場合もあります。この例では、3 つのリソースがあります。

• クライアント - クライアント。
• 注文 - 顧客の注文。
• アイテム - 商品。

クライアントは、いわゆるエンドポイントにリクエストを送信します。非常に簡単に言うと、エンドポイントはネットワーク上のアドレスのようなものです。さらに詳しく説明すると、エンドポイントはURIです。つまり、抽象リソースまたは物理リソースを識別する一連の文字です。統一リソース識別子 - 統一されたリソース識別子。エンドポイントまたは URI はパス、つまりリソー​​スへのパスと呼ばれることもあります。この記事では、URI という用語を使用します。特定のリソースにはそれぞれ一意の URI が必要です。各リソースが常に独自の URI を持つようにする責任はサーバー開発者の肩にあります。この例では、私たちは開発者なので、知っている方法でそれを行います。リレーショナル データベースでは主キーを特定の数値 ID に設定することが一般的であるのと同様に、REST では各リソースが独自の ID を持ちます。REST のリソースの ID が、このリソースに関する情報が保存されているデータベースのレコードの ID と一致することがよくあります。REST URI は通常、リソースを説明する名詞の複数形で始まります。たとえば、クライアントという言葉から。次に、ID はスラッシュで示されます。これは特定のクライアントの識別子です。例:

• /clients - すべての既存クライアントの URI。
• /clients/23 - 特定のクライアント、つまり ID=23 のクライアントの URI。
• /clients/4 - 特定のクライアント、つまり ID=4 のクライアントの URI。

しかし、それだけではありません。URI に注文を追加することで、URI を拡張できます。

• /clients/4/orders — クライアント No. 4 のすべての注文の URI。
• /clients/1/orders/12 - クライアント No. 1 のオーダー No. 12 の URI。

この連鎖を続けて商品を追加すると、次のようになります。

• /clients/1/orders/12/items — クライアント No. 1 が作成した注文 No. 12 の全製品リストの URI。

ネストレベルでは、URI を直感的にすることが重要です。

HTTPメソッド

HTTP メソッド (英語の HTTP メソッド) は、コントロールと区切り文字を除く任意の文字のシーケンスであり、リソースに対する主な操作を示します。一般的な HTTP メソッドがいくつかあります。RESTful サービスで最もよく使用されるものをリストします。

• GET - 特定のリソース (ID 経由) またはリソースのコレクションに関する情報を取得するために使用されます。
• POST - 新しいリソースの作成に使用されます。
• PUT - リソースを変更するために使用されます (ID 経由)。
• DELETE - リソースを (ID 経由で) 削除するために使用されます。

見出し

リクエストとレスポンスには HTTP ヘッダーが含まれます。リクエスト (またはレスポンス) に関する追加情報を送信します。ヘッダーはキーと値のペアです。最も一般的な見出しのリストは、Wikipediaページで読むことができます。REST を使用すると、クライアントは多くの場合、リクエスト内の Accept ヘッダーをサーバーに送信できます。クライアントがどのような形式で応答を受け取ることを期待しているかをサーバーに知らせる必要があります。さまざまな形式のオプションが、いわゆる MIME タイプ リストに表示されます。 MIME (MultiPurpose Internet Mail Extensions) は、インターネット上で送信できるように情報をエンコードし、メッセージをフォーマットするための仕様です。各 MIME タイプは、スラッシュで区切られたタイプとサブタイプの 2 つの部分で構成されます。さまざまな種類のファイルの MIME タイプの例:

• テキスト - テキスト/プレーン、テキスト/css、テキスト/html;
• 画像 - 画像/png、画像/jpeg、画像/gif;
• オーディオ - オーディオ/wav、オーディオ/mpeg;
• ビデオ - ビデオ/mp4、ビデオ/ogg;
• アプリケーション - application/json、application/pdf、application/xml、application/octet-stream。

全体として、リクエストには次のヘッダーが含まれる場合があります。

Accept:application/json

このヘッダーは、クライアントが JSON 形式で応答を受信することを期待していることをサーバーに伝えます。

リクエストボディ

クライアントからサーバーに送信されるメッセージ。リクエストにボディがあるかどうかは、HTTP リクエストのタイプによって異なります。たとえば、GET リクエストと DELETE リクエストには通常、リクエスト本文が含まれません。ただし、PUT と POST には以下を含めることができます。それはすべて、リクエスト タイプの機能的な目的に関するものです。結局のところ、ID (URL で送信される) によってデータを受信して​​削除するには、追加のデータをサーバーに送信する必要はありません。ただし、新しいリソース (POST リクエスト) を作成するには、このリソースを転送する必要があります。既存のリソースを変更する場合も同様です。REST では、リクエスト本文の送信に XML または JSON 形式が最もよく使用されます。最も一般的な形式は JSON です。サーバーにリクエストを送信し、その中に新しいリソースを作成するとします。覚えていると思いますが、例として、顧客の注文を管理するアプリケーションを取り上げました。新しいクライアントを作成したいとします。私たちの場合、クライアントに関する次の情報を保存します: 名前 電子メール 電話番号 このようなリクエストの本文は次の JSON になる可能性があります。

{
  "name" : "Amigo",
  "email" : "amigo@jr.com",
  "phone" : "+7 (191) 746-43-23"
}

リクエストをまとめる

そこで、クライアントのリクエストがどのようなもので構成されているかを調べました。クエリの例を説明とともにいくつか挙げてみましょう

答え

サーバーの応答について少し言ってみましょう。通常、答えは次の部分で構成されます。

• 応答コード。
• ヘッダー。
• レスポンスボディ。

一般に、応答ヘッダーは要求ヘッダーとそれほど変わりません。さらに、一部のヘッダーは応答と要求の両方で使用されます。応答の本文でもすべてが明らかだと思います。多くの場合、本文はクライアントが要求した情報を返します。情報は、GET リクエストの場合と同じ JSON 形式で返すことができます。しかし、最後の部分はもう少し興味深いです。

HTTPレスポンスコード

HTTP 応答コードを詳しく見てみましょう。以下は Wikipedia からの引用です。HTTP ステータス コードは、 HTTP プロトコル経由のリクエストに対するサーバー応答の最初の行の一部です。10 進数 3 桁の整数です。最初の数字は状態のクラスを示します。通常、応答コードの後に​​はスペースで区切られた英語の説明フレーズが続き、この特定の応答の理由をユーザーに説明します。例:

• 201 が作成されました。
• 401 無許可。
• 507 ストレージが不十分です。

クライアントは、応答コードからリクエストの結果を学習し、次にどのようなアクションを実行するかを決定します。応答コードはいくつかのグループに分類されます。

• 1ХХ - 情報;
• 2ХХ - クライアントのリクエストの受け入れと処理が成功したケースについて通知します。
• 3XX - 操作を正常に完了するには、通常は別の URI を使用して別のリクエストを行う必要があることをクライアントに通知します。
• 4ХХ - クライアント エラー。たとえば、誤って構築されたリクエストや、クライアントが存在しないリソースをリクエストしたときに発生する可能性があるよく知られた 404 Not Found コードなどです。
• 5ХХ - サーバーエラー。サーバーの障害により操作が失敗した場合にクライアントに返されます。

すべてのコードの詳細については、ここで読むことができます。 パート 1: REST とは パート 3: Spring Boot での RESTful サービスの作成