1. 序章

多くの場合、RESTとHTTPという用語は同じ意味で使用されます。 この記事では、各用語が実際に何を意味するのか、そしてなぜそれらが2つの異なるものであるのかを見ていきます。

2. RESTとは何ですか？

RESTは、Representational StateTransferの略です。 これは、RoyFieldingの現在有名な論文で最初に説明されました。 このホワイトペーパーでは、フィールディングは、ワールドワイドウェブの理想的なソフトウェアアーキテクチャのビジョンを示しました。

RESTは標準または仕様ではありません。 代わりに、フィールディングは、RESTを分散型ハイパーメディアシステムのアーキテクチャスタイルとして説明しました。 彼は、RESTfulアーキテクチャには、インターネットなどの大規模な相互接続システムに理想的ないくつかの属性があると信じていました。

次に、RESTfulシステムを定義する属性を見ていきます。

2.1. リソースと表現

RESTfulシステムのコアビルディングブロックはリソースです。 リソースには、たとえば、Webページ、ビデオストリーム、または画像があります。 リソースは、データベース内のすべてのユーザーのリストや特定の場所の天気予報など、抽象的な概念にすることもできます。 唯一の実際の制約は、システム内のすべてのリソースが一意に識別可能であるということです。

さらに、リソースは複数の表現で利用できる場合があります。 クライアント/サーバーモデルでは、サーバーがリソースの状態を管理しますが、クライアントはと対話する表現を選択できます。

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

統一されたインターフェースは、RESTfulシステムの特徴的な属性の1つです。 クライアントは、同じ一連の標準操作を使用してすべてのリソースにアクセスする必要があります。

統一されたインターフェースの利点は、提供するサービスから切り離された実装を簡単に作成できることです。 これにより、クライアントに影響を与えることなくサービスを進化させることができます。 トレードオフは、統一されたインターフェイスが一部のシステムに不要な制限を課したり、サーバーが特殊な操作を使用した場合よりも効率が低下したりする可能性があることです。

2.3. ステートレス

RESTfulシステムでのすべての操作はステートレスである必要があります。 つまり、クライアントからサーバーへの各呼び出しは、共有状態に依存してはなりません。 また、サーバーへのすべての要求には、サーバーが要求を満たすために必要なすべてのデータが含まれている必要があることも意味します。

RESTのステートレス要件は、いくつかの重要なプロパティに取って代わられます。

  • 可視性：各リクエストを個別に分析して、システムの状態と応答性を監視できます
  • 信頼性：システム障害からの回復が容易
  • スケーラビリティ：より多くのリクエストを処理するためにサーバーリソースを追加するのは簡単です

ただし、クライアントがサーバーと複数の対話を行う場合、サーバーへの要求が大きくなり、反復データが含まれるというトレードオフも伴います。

3. HTTPとは何ですか？

RESTとは異なり、ハイパーテキスト転送プロトコル（HTTP）は、明確に定義された制約を備えた標準です。 HTTPは、インターネット上での日常的なやり取りのほとんどを強化する通信プロトコルです。

  • WebページをロードするWebブラウザ
  • ビデオのストリーミング
  • モバイルデバイスを使用して家の電気を消す

では、RESTはHTTPと同じものですか？ 簡単な答えはノーです。

HTTPは、インターネット技術特別調査委員会によって維持されているプロトコルです。 これはRESTと同じではありませんが、RESTfulシステムの多くの機能を備えています。 RoyFieldingはRFCforHTTPの最初の作成者の一人であったため、これは偶然ではありません。

RESTfulシステムではHTTPの使用は必要ないことを覚えておくことが重要です。 HTTPは、RESTfulな品質を数多く備えているため、たまたま良いスタートを切ることができます。

HTTPをRESTfulプロトコルにするいくつかの品質を詳しく見てみましょう。

3.1. URLとメディアタイプ

HTTPの世界では、リソースは通常、リモートサーバー上のファイルです。 これらは、HTML、CSS、JavaScript、画像、および最新のWebページを構成する他のすべてのファイルである可能性があります。 各ファイルは、一意のURLを使用してアドレス指定できる個別のリソースとして扱われます。

ただし、HTTPはファイルだけのものではありません。 リソースという用語は、リモートサーバー上の任意のデータを指すこともあります：顧客、製品、構成設定など。 これが、最新のAPIを構築するためにHTTPが普及した理由です。 これは、リモートデータにアクセスして操作するための一貫した予測可能な方法を提供します。

さらに、 HTTPを使用すると、クライアントは一部のリソースに対して異なる表現を選択できます。 HTTPでは、これはヘッダーとさまざまなよく知られたメディアタイプを使用して処理されます。

たとえば、天気Webサイトは、同じ天気予報に対してHTML表現とJSON表現の両方を提供する場合があります。 1つはWebブラウザでの表示に適しており、もう1つは過去の気象データをアーカイブする別のシステムによる処理に適しています。

3.2. HTTPメソッド

HTTPがRESTの原則に準拠するもう1つの方法は、すべてのリソースに同じメソッドのセットを提供することです。 利用可能なHTTPメソッドは12近くありますが、ほとんどのサービスは主にCRUD操作にマップする4つを処理します： POST 、 GET 、 PUT [ X169X]、およびDELETE。

これらの操作を事前に知っていると、Webサービスを使用するクライアントを簡単に作成できます。 操作をカスタマイズして無制限にできるSOAPなどのプロトコルと比較すると、HTTPは既知の一連の操作を最小限に抑えて一貫性を保ちます。

もちろん、個々のWebサービスは、一部のリソースに対して特定のメソッドを拒否することを選択する場合があります。 または、機密リソースの認証が必要です。 とにかく、possible HTTPメソッドのセットはよく知られており、Webサイトごとに異なることはできません。

3.3. HTTPは必ずしもRESTfulではありません

ただし、HTTPがRESTful原則を実装するすべての方法について、HTTPがそれらに違反する可能性のある複数の方法があります。

まず、RESTは通信プロトコルではありませんが、HTTPは通信プロトコルです。

次に、おそらく最も物議を醸すのは、最新のWebサーバーのほとんどがCookieとセッションを使用して状態を保存することです。 これらがサーバー側の状態を参照するために使用される場合、これはステートレスの原則に違反します。

最後に、 URL（IETFで定義されている）を使用すると、Webサーバーがユニフォームインターフェイスに違反する可能性があります。 たとえば、次のURLについて考えてみます。

https://www.foo.com/api/v1/customers?id=17&action=clone

このURLは、 GET などの事前定義されたHTTPメソッドの1つを使用して要求する必要がありますが、追加の操作を提供するためにクエリパラメーターを使用しています。 この場合、システム内のすべてのリソースで明らかに使用できるわけではないcloneという名前のアクションを指定しています。 また、サービスに関するより詳細な知識がなければ、どのような対応になるかは明確ではありません。

4. 結論

多くの人がRESTとHTTPという用語を同じ意味で使用し続けていますが、真実はそれらが異なるものであるということです。 RESTは、特定のアーキテクチャスタイルの属性のセットを指しますが、HTTPは、RESTfulシステムの多くの機能をたまたま示す明確に定義されたプロトコルです。