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

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

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

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

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

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

• HTTP;
• URL と URI。
• JSON と、程度は低いですが XML。
• 依存関係の注入。

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

IT 世界の多くのものと同様、REST はRepresentational State Transferの頭字語です。これは、コンピュータ ネットワーク内の分散システム コンポーネント間の対話のアーキテクチャ スタイルです。簡単に言うと、REST は、システムの異なるコンポーネント間の対話 (データ交換) のスタイルを定義します。各コンポーネントは物理的に異なる場所に配置されます。このアーキテクチャ スタイルは、分散システムの設計時に考慮される一貫した一連の制約を表します。これらの制限は、REST 原則と呼ばれることもあります。数は多くなく、6個のみです。それらについては後ほど説明します。

RESTの歴史

REST という用語は、HTTP プロトコルの作成者の 1 人である Roy Fielding が 2000 年に博士論文「Architectural Styles and the Design of Network-based Software Architectures」の中で作った造語です。REST という用語はまだ新しいと言えますが、その概念は World Wide Web のまさに基礎にあります。この用語の起源の歴史については深く掘り下げません。オリジナルの情報源を詳しく知りたい場合は、フィールディングの論文を参照してください。

RESTの制限と原則

上で述べたように、REST は分散システムのコンポーネントがどのように相互作用するかを定義します。一般に、これはリクエストとレスポンスを通じて行われます。リクエストを送信するコンポーネントはクライアントと呼ばれます。リクエストを処理し、クライアントに応答を送信するコンポーネントはサーバーと呼ばれます。リクエストとレスポンスは、ほとんどの場合、HTTP (HyperText Transfer Protocol) 経由で送信されます。通常、サーバーはある種の Web アプリケーションです。クライアントは何でもあり得るわけではなく、非常に多くのクライアントになる可能性があります。たとえば、サーバーにデータを要求するモバイル アプリケーションです。または、データをダウンロードするために Web ページからサーバーにリクエストを送信するブラウザー。アプリケーション A はアプリケーション B にデータを要求できます。この場合、A は B に対してクライアントとなり、B は A に対してサーバーになります。同時に、A は C、D、D などからのリクエストを処理できます。この場合、アプリケーション A はサーバーでもありクライアントでもあります。それはすべてコンテキストに依存します。1 つ明らかなことは、リクエストを送信するコンポーネントはクライアントであるということです。リクエストを受信、処理し、応答するコンポーネントはサーバーです。ただし、コンポーネントがリクエストとレスポンスを介して通信するすべてのシステムが REST (または RESTful) システムであるわけではありません。システムが RESTful であるとみなされるには、次の 6 つの REST 制約に「適合」する必要があります。

1. アーキテクチャをクライアント/サーバー モデルに移行する

この制限の基礎はニーズの区別です。クライアント インターフェイスのニーズとデータを保存するサーバーのニーズを分離する必要があります。この制限により、クライアント コードの他のプラットフォームへの移植性が向上し、サーバー部分の簡素化によりシステムのスケーラビリティが向上します。「クライアント」と「サーバー」のまさに区別により、それらは互いに独立して開発できます。

2. コンディションの欠如

REST アーキテクチャでは、次の条件を満たす必要があります。リクエスト間では、サーバーはクライアントの状態に関する情報を保存する必要はなく、その逆も同様です。クライアントからのすべてのリクエストは、サーバーがリクエストを完了するために必要なすべての情報を受信できるように構成されている必要があります。このようにして、サーバーとクライアントの両方が、以前のメッセージに依存せずに、受信したメッセージを「理解」できます。

3. キャッシング

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

4. 界面の均一性

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

5. レイヤー

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

6. コードオンデマンド（オプションの制限）

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

RESTの利点

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

• パフォーマンス (キャッシュの使用による)。
• スケーラビリティ;
• インタラクションシステムの透明性。
• インターフェイスのシンプルさ。
• コンポーネントの移植性。
• 変更の容易さ。
• 新しい要件に適応して進化する能力。

パート 2: クライアントとサーバー間の通信 パート 3: Spring Boot での RESTful サービスの作成