REST の概要。パート 1: REST とは何ですか?

やあ！今日は、非常に興味深い、そして最も重要なことに、労働市場で需要が高いトピックである REST について学びます。 REST の概要を 3 つの部分に分けて説明します。

1. 最初の部分では、REST の歴史を説明し、REST の基礎となる原則について説明します。

2. 2 番目のセクションでは、HTTP プロトコルを介してクライアントとサーバー間の通信がどのように行われるかを検討します。

3. 3 番目では、「Postman」というプログラムを使用してテストする小さな RESTful アプリケーションを作成します。

この記事は、次の用語に精通している読者を対象としています。

• HTTP
• URLとURI
• JSON および (程度は低いですが) XML
• 依存関係の注入

パート 1. REST とは何ですか?

IT 業界の多くの場合と同様、REST は頭字語です。これは、「REpresentational State Transfer」から派生したものです。これは、コンピュータ ネットワーク内の分散システムのコンポーネント間の対話のためのアーキテクチャ スタイルです。簡単に言えば、REST は、システムのさまざまなコンポーネント間の対話 (データ交換) のスタイルを決定します。各コンポーネントは物理的に異なる場所に配置できます。このアーキテクチャ スタイルは、分散システムを設計するときに遵守される一貫した一連の制約です。これらの制約は、REST の指導原則と呼ばれることもあります。数は多くはなく、6 つだけです。それらについては少し後ほど説明します。

RESTの歴史

REST という用語は、HTTP プロトコルの作成者の 1 人である Roy Fielding によって博士論文で導入されました。REST という用語はまだ若いと言えますが、それが表す概念は World Wide Web のまさに核心にあります。この用語の歴史については深く掘り下げません。一次情報源を詳しく知りたい場合は、フィールディングの 論文を参照してください。

RESTの制約と原則

上で述べたように、REST は分散システムのコンポーネントがどのように相互作用するかを定義します。一般に、これは要求と応答のプロセスを通じて発生します。リクエストを送信するコンポーネントはクライアントと呼ばれ、リクエストを処理してクライアントに応答を送信するコンポーネントはサーバーと呼ばれます。。リクエストとレスポンスは、ほとんどの場合、HTTP プロトコル経由で送信されます。HTTP はハイパーテキスト転送プロトコルの略です。通常、サーバーは何らかの Web アプリケーションです。クライアントはほぼ何でも構いません。たとえば、サーバーにデータを要求するモバイル アプリです。または、データをダウンロードするために Web ページからサーバーにリクエストを送信するブラウザー。アプリケーション A はアプリケーション B にデータを要求する場合があります。この場合、A は B に対してクライアントであり、B は A に対してサーバーです。同時に、A は B、C、D などからの要求を処理できます。この場合、アプリケーション A はサーバーでもありクライアントでもあります。すべてはコンテキストに依存します。1 つ確かなことは、リクエストを送信するコンポーネントはクライアントであるということです。リクエストを受信、処理し、応答するコンポーネントはサーバーです。しかし、コンポーネントが要求/応答プロセスを通じて通信するすべてのシステムが RESTful システムであるわけではありません。システムが RESTful であるとみなされるには、次の 6 つの REST 制約に準拠する必要があります。

1. クライアントサーバーアーキテクチャ

この制約は関心事の分離に関するものです。クライアント インターフェイスの要件とデータを保存するサーバーの要件を分離する必要があります。この制約により、クライアント コードは他のプラットフォームへの移植性が高まり、サーバー側が簡素化されることでシステムのスケーラビリティが向上します。「クライアント」と「サーバー」を区別することで、それぞれを独立して開発できるようになります。

2. ステートレス

RESTful アーキテクチャでは、次の条件を満たす必要があります。リクエスト間の期間中、サーバーはクライアントの状態に関する情報を保存してはなりません。逆も同様です。クライアントからのすべてのリクエストは、リクエストを完了するために必要なすべての情報をサーバーに提供する方法で作成する必要があります。したがって、サーバーとクライアントはどちらも、以前のメッセージに依存せずに、受信したメッセージを「理解」できます。

3. キャッシュ可能

クライアントはサーバーの応答をキャッシュできます。これらは、クライアントが後続のリクエストに応じて古いデータや間違ったデータを受信しないように、明示的または暗黙的にキャッシュまたは非キャッシュとして指定する必要があります。適切なキャッシュにより、一部のクライアントとサーバーの対話が完全または部分的に排除され、システムのパフォーマンスとスケーラビリティがさらに向上します。

4. 統一されたインターフェース

RESTful アーキテクチャの基本要件には、統一された均一なインターフェイスが含まれます。クライアントは、リクエストを送信するときに使用する必要がある形式とアドレスを常に理解する必要があり、サーバーも、クライアントのリクエストに応答するときに使用する必要がある形式を理解する必要があります。データを、どこに、どのような形式で、どのように送信するかを説明するこの一貫したクライアントとサーバーの対話が、統一インターフェイスです。

5. レイヤー

レイヤーとは、ネットワークの階層構造を意味します。クライアントはサーバーと直接通信できる場合もあれば、中間ノードとのみ通信する場合もあります。中間サーバーを使用すると、負荷分散と分散キャッシュによりスケーラビリティが向上します。例を挙げてみましょう。世界中で人気のあるモバイル アプリを想像してみてください。アプリの不可欠な部分には、画像の読み込みが含まれます。ユーザーの数は数百万人に達するため、単一のサーバーではそのような重い負荷を処理できません。システムを複数の層に分割すると、この問題が解決されます。クライアントが中間ノードに画像を要求した場合、中間ノードはその時点で最も負荷がかかっていないサーバーに画像を要求し、その画像をクライアントに返します。キャッシュが階層の各レベルで正しく適用されている場合、

6. コードオンデマンド (オプション)

この制約は、クライアントがアプレットまたはスクリプトの形式でサーバーからコードをダウンロードすることで機能を拡張できることを意味します。

RESTful アーキテクチャの利点

前述のすべての制約に準拠するアプリケーションには、次の利点があります: 信頼性 (失われる可能性があるクライアントの状態を保存する必要がない)

• パフォーマンス (キャッシュの使用による)
• スケーラビリティ
• 透明性のあるコミュニケーション
• シンプルなインターフェース
• 携帯性
• 簡単に変更を加える能力
• 新しい要件に進化して適応する能力

REST の概要。パート 2: クライアントとサーバー間の通信 REST の概要。パート 3: Spring Boot での RESTful サービスの構築