RESTアーキテクチャ

投稿日: 2022-11-04 2022-11-04
タグ: Software Architecture

1. 序章

RESTは、リソースを定義してアクセスする方法を説明するルールに依存するソフトウェアアーキテクチャスタイルです。 Googleトレンドでわかるように、RESTへの関心は非常に大きいです。 RESTfulAPIなしで現代のインターネットを想像するのは難しいです。この記事では、RESTおよび関連するHTTPの概念について詳しく説明します。

2. RESTアーキテクチャ

前述したように、RESTはソフトウェアアーキテクチャスタイルです。一方、標準化されていません（ SOAP など）。実装に関しては、多くの弾力性があります。たとえば、ページネーションを実装するための単一の適切な方法はありません。したがって、 RESTは、RESTfulAPIを開発する際に従うべき主要な一般的な制約のセットを定義します。それらを定義しましょう。

2.1. 制約

均一なインターフェース。特定のリソースをリクエストで特定する必要があります。通常、これらは Unix Resource Identifier （URI）によって記述されます。さらに、内部実装はリソース表現とは別のものです。さらに、表現は、リソースを変更または削除したり、追加のデータをフェッチしたりするためのすべての情報を提供する必要があります。
クライアントサーバーアーキテクチャ。クライアントはURIを使用してリソースを取得します。サーバーがリクエストを処理する方法は関係ありません。一方、サーバーはリソースを処理して返します。ユーザーインターフェイスにはまったく影響しません。クライアントとサーバーの両方が他の責任について知る必要はありません。したがって、それらは独立して進化することができます。これにより、Webブラウザー、モバイルアプリなど、さまざまなクライアントで単一のAPIを使用できます。
ステートレス。RESTfulAPIはステートレスである必要があります。簡単に言うと、ユーザーのセッションに関する情報が保存されていないことを意味します。したがって、すべてのリクエストは、それを処理するための完全なデータを提供する必要があります。したがって、APIの可用性が向上します。
キャッシュ可能性。サーバーの応答は、キャッシュする必要があるかどうか、およびその時間に関する情報を提供する必要があります。キャッシュ更新するデータがパフォーマンスを向上させることはめったになく、冗長なクライアント/サーバー相互作用を排除します。
レイヤードシステム。RESTAPIは、ビジネスロジック、プレゼンテーション、データアクセスなどの複数のレイヤーで構成できます。さらに、レイヤーが他のレイヤーに直接影響を与えてはなりません。さらに、クライアントは、エンドサーバーに直接接続されているのか仲介者に接続されているのかを知る必要はありません。したがって、システムを簡単に拡張したり、ゲートウェイ、プロキシ、ロードバランサーなどの追加のレイヤーを提供したりできます。
オンデマンドコード。これはオプションの制約です。サーバーは、JSON形式のデータではなく、コード自体の一部を返すことができます。重要なのは、クライアントが直接使用できるデータに対する特定の操作を提供することです。ただし、これは一般的な方法ではありません。

3. HTTPプロトコル

RESTを考えると、私たちは通常HTTPベースのアプリケーションを考えます。ただし、さまざまなプロトコルにRESTを使用することは可能ですが、それが発生することはめったにありません。したがって、このセクションでは、HTTPプロトコルとRESTでのその使用法に焦点を当てます。

まず、HTTPプロトコルはWorldWideWebのプロトコルです。これは、クライアントとサーバー間の通信のルールを定義します。 HTTPはステートレスであり、要求/応答アプローチで機能します。

クライアントは、あるリソースに関連するリクエストを送信します。 HTML Webサイト、ファイル、またはJavaScriptコードにすることができます。 HTTPは、リソースがどうあるべきかを定義しません。 各リソースには、URIを呼び出す独自の識別子があります。 URIの一般的な構造は次のようになります。

scheme:[//[user[:password]@]host[:port]][/path][?query][#fragment]

明確にするために、実際の例を見てみましょう。

URIはHTTPリクエストの一部にすぎません。リクエストの内容は次のとおりです。

パス、プロトコルバージョン、およびHTTPメソッドを含む要求行
0個以上のヘッダー
ヘッダーの終わりを示す空の行
オプションのボディ

3.1. メソッド

HTTPリクエストはリクエストラインで構成されており、HTTPメソッドがあることはすでに知っています。 HTTPメソッドは、クライアントがリソースに対して実行するアクションを記述します。 GET、POST、PUT、およびDELETEの4つの基本的な最もよく使用されるメソッドがあります。それらを定義しましょう。

最初のGETは、リソースの読み取りに使用されます。サーバーは、指定されたURIのリソースを返します。 GETメソッドには本文が含まれていません。リソースをフェッチするだけで、変更することはありません。

2番目のPOSTは、サーバーにデータを転送するために使用されます。したがって、通常はリソースの作成に関連付けられています。データは本文で送信されます。リソースが作成された後、サーバーはそのURIで応答する必要があります。

次のPUTはPOSTに似ています。ただし、大きく異なります。既存のリソースを更新するために使用されます。転送されたデータでリソース全体をオーバーライドします。 PUTとPOSTの主な特性は、PUTがべき等演算であるということです。つまり、同じデータを使用してPUTを何度も呼び出すと、常に同じ結果が得られます。副作用はありません。さらに、PUTは既存のリソースを指します。 POSTは新しいものを作成します。

最後の基本的なメソッドはDELETEです。名前が示すように、既存のリソースを削除するために使用されます。

時々使用される可能性のある追加のメソッドもあります：PATCH、HEAD、OPTIONS、CONNECT、およびTRACE。ただし、使用されることはめったにないため、この記事では取り上げません。

3.2. コード

HTTP応答には応答コードが付属しています。操作の結果を通知します。コードに基づいて適切なアクションを実行できるため、UI開発者にとって特に便利です。 HTTP応答コードには次のグループがあります。

1xx –情報–要求が受信され、プロセスが続行されたことを示します。例は次のとおりです。100–続行、101 –プロトコルの切り替え
2xx –成功–リクエストが受信され、理解され、正常に処理されたとき。よく知られている例は、200 –OKおよび201–作成済みです。
3xx –リダイレクト–クライアントは、要求を満たすために追加のアクションを実行する必要があります。たとえば、300 –複数選択または301 –永続的に移動
4xx –クライアントエラー–クライアント側にエラーがあることを示します。たとえば、400 –不正な要求または401 –無許可です。
5xx-サーバーエラー–サーバー側でエラーが発生したことを通知します。例：500 –内部サーバーエラー、501 –未実装

4. リチャードソン成熟度モデル

簡単に言うと、 Richardson Maturity Modelは、RESTfulAPIの要件への準拠レベルを推定します。モデルは4つのレベルを定義します。 APIがそれらすべてを満たしている場合、それはモデルを完全に実装していることを意味します。したがって、RESTの制約を考慮すると、APIの品質が高いことを示しています。

レベル0はPOXの沼と呼ばれます。そのレベルでは、APIはHTTPプロトコルの可能性を最大限に活用するのではなく、通常、POSTメソッドとGETメソッドのみを使用します。したがって、HTTPプロトコルはトランスポート層としてのみ使用されます。さらに、ほとんどの場合、応答コード200が返されます。さらに、実装は明確に定義されたURIに依存しません。レベル0APIのエンドポイントの例は次のようになります。

POST /api/createUser
POST /api/updateUser
GET /api/findUser

レベル1APIは、リソースとそのURIを定義します。ただし、追加のHTTPメソッドと応答コードは使用されません。レベル1APIのURIの例は次のとおりです。

POST /api/users/create
GET /api/users/{id}/find
POST /api/users/{id}/update

レベル2のAPIは、GETおよびPOSTの他に、PUT、PATCH、DELETEなどの追加のHTTPメソッドを使用します。したがって、URIはより適切に定義されます。さらに、APIはより意味のあるHTTP応答コードを使用します。以下に、レベル2APIエンドポイントの例を示します。

POST /api/users
PUT /api/users/{id}
GET /api/users/{id}

最後に、レベル3ではHATEOASが導入されます。これは自己ナビゲートAPIです。複雑さが増すため、あまり使用されません。簡単に言うと、要求されたリソースに関連する追加リソースのURIを追加します。明確にするために、以下の例を見てみましょう。ユーザーの応答では、アドレスURIを埋め込み、それを使用することで、クライアントはアドレスの詳細を取得できます。

{
   "id":12345,
   "firstname":"some-firstname",
   "lastname":"some-lastname",
   "age":39,
   "links":{
      "address":"users/12345/address"
   }
}

5. 結論

この記事では、RESTアーキテクチャの基本と制約を定義しました。さらに、HTTPプロトコルとRESTfulAPIでのその使用法についても説明しました。 RESTは堅固で弾力性のあるアーキテクチャであることがわかります。したがって、これは非常に人気があり、多くの最新のAPIで広く使用されています。

getdocs

13036