ウェブ開発において、表現状態転送（REST）という概念ほど混乱を招く話題はありません。この用語は、第5章 ロイ・フィールディング氏のカリフォルニア大学アーバイン校における博士論文から来ています。
このエッセイでは、この章を詳しく見て、非学術的なウェブ開発者にとって重要な概念をまとめます。この論文は難解であり、正式な博士論文執筆に関心のない人々には関係のない多くの専門用語が含まれています。
このエッセイの最後までに、RESTと、特に統一インターフェースの概念について、より深く理解できるようになるでしょう。
RESTについて最初に理解すべきことは、それが元のウェブの説明であるということです。フィールディングはRESTを「分散ハイパーメディアシステムのためのアーキテクチャスタイル」と説明していますが、これは私たちがよく知っているウェブ、つまりハイパーリンクをクリックしたり、フォームを送信したり、画像を見たり、段落を読んだりといったことを意味します。
RESTは、JSON APIに関する特定のアプローチの説明として作成されたものではありません。現在、多くの人がRESTについて耳にする文脈はそれですが、フィールディングは初期のウェブ、特にそれが以前のクライアント/サーバーアーキテクチャとどのように異なるかを説明していました。
5.1節では、残念ながら非学術的な人々にとっては、フィールディングは第一原理からRESTを導き出す手法を採用しています。ここでは、各セクションを要約し、重要なセクションでは説明を追加して文脈を追加します。
RESTは、ウェブがクライアント（ブラウザ）サーバー（HTTPサーバー）システムであるため、クライアントサーバーアーキテクチャです。
ほとんどの開発者は、ウェブはステートレスであることを意図していると知っています。すべてのリクエストは、そのリクエストを理解するために必要なすべての情報をカプセル化する必要があります。たとえば、SQLデータベースセッションのように、一連のリクエストに暗黙的に関連付けられた長時間実行トランザクションがあってはなりません。
HTTPには、おそらくご存知のように、キャッシングメカニズムが組み込まれています。今のところ、その詳細は知る必要はありませんが、後で調べることができます。
このセクションは、私の考えでは、RESTアーキテクチャの中心であり、残念ながら非常に簡潔であるため、要約するのではなく、詳しく説明します。この章は次のように始まります。
RESTアーキテクチャスタイルを他のネットワークベースのスタイルと区別する中心的な特徴は、コンポーネント間の統一インターフェースの強調です。
統一インターフェースが正確にどのようなものであるかについての議論を明確にするために、この記事を読んでいるすべての人が理解できるであろう単純なHTMLについて考えてみましょう。
<html>
<body>
<section>
<p>
Name: Joe Blow
</p>
<p>
Email: joe@blow.com
</p>
<p>
<a href="/contacts/42/edit">Edit</a>
<a href="/contacts/42/email">Email</a>
<a href="/contacts/42/archive">Archive</a>
</p>
</section>
</body>
</html>
ここでは、いくつかのdiv、いくつかの情報、そして連絡先に対してさまざまな操作を実行するためのいくつかのアンカータグを含む基本的なHTMLがあります。派手なものではありません。繰り返しますが、この議論では、このコンテンツはhttp://example.com/contacts/42で見つかる可能性があると想像してください。
論文に戻りましょう。
RESTは、リソースの識別、表現によるリソースの操作、自己記述メッセージ、およびハイパーメディアとしてのアプリケーション状態のエンジンという4つのインターフェース制約によって定義されます。
順番に見ていきましょう。
RESTの最初の側面は、…まあ、ユニバーサルリソースロケータ（URL）を介してどこかで見つかるリソースのアイデアです。HTMLには、従来の階層的なURLパスの配置に従って、このリソース（`contacts/42`）に対して実行できるアクションの追加URLが含まれていることに注意してください。
これは難しく聞こえますが、単に、SQLを使用して変更するのではなく、さまざまな表現（つまりHTMLページ）を介してリソース（つまり連絡先）を更新および変更できることを意味します。
これはRESTの重要な概念です。クライアントサーバー設定におけるクライアントであるブラウザは、連絡先について何も知りません。それでも、サーバーによって返されたHTMLをレンダリングするだけで、「連絡先UI」をレンダリングできます。メッセージ自体は完全に自己記述的であり、クライアントが必要とするデータとデータに対する可能な操作の両方のすべての情報（リンクの形で）が含まれています。
さて、これと同じデータのJSON表現と比較してみましょう。
{
"name" : "Joe Blow",
"email" : "joe@example.com"
}
明らかにこれは小さいですが、このデータを使用するクライアントは2つの重要なことを決定する必要があります。
最初の部分は通常、クライアント側のテンプレートで行われます。2番目は、通常、APIのドキュメントを読み、サーバーとの対話をクライアントに直接エンコードすることによって行われます。
これが、RESTfulシステムと従来のクライアントサーバーシステムの違いの中心です。RESTfulシステムでは、クライアント（つまりブラウザ）はリソースについて何も知りません。ハイパーメディアをレンダリングする方法だけを知っています。クライアントサーバーシステムでは、リソースに関する知識はクライアントに埋め込まれています。
どちらのアプローチにも長所と短所がありますが、初期のウェブの形をしたRESTfulアプローチは、非常に信頼性が高く柔軟であることが証明されました。このHTMLの統一インターフェースの背後にある膨大な量の資源に関する知識が隠されているため、クライアントはシッククライアントのように壊れる機会がありません。
さて、ここ10年で、ウェブ開発はRESTfulアーキテクチャから、JSON APIを使用するより従来のクライアントサーバー設定へと移行していることに気付いたかもしれません。そして、APIのバージョン管理、より一般的なクエリ機能の提供などに関する多くの議論や問題に気付いたかもしれません。これは偶然ではありません。ブラウザをシッククライアントアプリケーションをホストするためのVMに変えるにつれて、RESTfulモデルの柔軟性を失っています。
この最後の概念は、前の概念と密接に関連しています。クライアントは、ハイパーメディア自体（フォームとリンクを介して）で見つかったURLと対話することにより、アプリケーションの状態を遷移します。したがって、上記のHTMLの例では、連絡先を編集、メール、アーカイブする機能はすべて、HTMLのアンカーとしてエンコードされています。これらのアクションのいずれかが使用できなくなったり、新しいアクションが使用可能になったりした場合、ページの更新後に新しいHTMLの一部として表示されます。
これは、たとえば、ローカルストアがバックエンドと非同期的に同期される可能性のあるシッククライアントアプローチとは対照的です。そのため、HTMLはアプリケーションの状態のエンジンとして機能しているのではなく、（ややぎこちない）UI記述言語として機能しています。
HATEOASに関するWikipediaの記事は、自然なハイパーメディアではないJSONを使用しているという、やや滑稽な点があります。必要に応じて、JSONの上にいくつかのRESTfulな動作をレイヤーできますが、現実世界ではほとんど役に立たず、HATEOASはJSON APIでは通常無視されます。これは、JSON APIは主に従来のクライアントサーバーアーキテクチャに役立ち、RESTfulスタイルには特に適していないためです。
これがRESTの中心であり、このエッセイの中心でもあります。フィールディングの論文についてもう少し詳細に分析するために読み進めることができますが、ここでの主なポイントは、RESTfulハイパーメディアアーキテクチャと従来のクライアントサーバーアーキテクチャの間に明確な違いがあり、その違いは主に統一インターフェースの概念、特にそれらの自己記述的な性質を中心に展開しているということです。
繰り返しますが、ここで専門用語にこだわらないでください。このHTMLについて考え、それがどれほど柔軟で独創的な奇跡であるかを考えてください。
<html>
<body>
<div>
<div>
Name: Joe Blow
</div>
<div>
Email: joe@blow.com
</div>
<div>
<a href="/contacts/42/edit">Edit</a>
<a href="/contacts/42/email">Email</a>
<a href="/contacts/42/archive">Archive</a>
</div>
</div>
</body>
</html>
CDNが存在することと、それらを使用する必要があること以外は、これについて多くを知る必要はありません。
JavaScriptが存在することと、それが唯一のオプションの部分であること以外は、これについて多くを知る必要はありません。
このセクションについては、他のセクションほど深く掘り下げません。かなり技術的になり、率直に言って、（論文で予想されるように）少し退屈で反復的だからです。このセクションの2つの大きなアイデアは、リソースと表現です。
論文から引用します。
RESTにおける情報の主要な抽象化はリソースです。名前を付けることができる情報であれば何でもリソースになります。ドキュメントや画像、時間的なサービス（例：「ロサンゼルスの今日の天気」）、他のリソースのコレクション、非仮想オブジェクト（例：人）などです。
実際には、リソースとはURLでアドレス指定できるものです。URLにアクセスすると何が起こりますか？
HTML、ディレクティブなどを含むHTTPレスポンスの形で、そのリソースの表現が返されます。
このセクションは、実用的な用途があまり見当たりません。制御データ、メディアタイプなど、いずれ必要になった際に学ぶ価値のある内容もありますが、Web開発で一般的に使用される側面ではありません。
同様に、残りのセクション5.2も、一般の開発者にとってそれほど役立つ情報はありません。
パターンになりつつありますが、このセクションにも、平均的なWeb開発者にとって多くの新しい有用な情報はないと感じます。ただし、大きな例外が1つあります。それは、RESTの利点を明確に示している点です。
論文から引用します。
RESTのクライアント・サーバー間の懸念事項の分離により、コンポーネントの実装が簡素化され、コネクタセマンティクスの複雑さが軽減され、パフォーマンスチューニングの効率が向上し、純粋なサーバーコンポーネントのスケーラビリティが向上します。階層化されたシステムの制約により、プロキシ、ゲートウェイ、ファイアウォールなどの仲介者を通信のさまざまなポイントに導入しても、コンポーネント間のインターフェースを変更する必要がなくなり、通信変換を支援したり、大規模な共有キャッシングを介してパフォーマンスを向上させることができます。RESTは、メッセージを自己記述的に制約することで、中間処理を可能にします。リクエスト間のインタラクションはステートレスであり、標準的なメソッドとメディアタイプを使用してセマンティクスを示し情報を交換し、レスポンスはキャッシュ可能性を明示的に示します。
これはすべて真実であり、Webがこれほど成功し、これからも成功し続ける理由です。
これらの短いセクションは、RESTに関心のある非学術者には関係ありません。
このように、RESTという用語を与えてくれたRoy Fieldingの論文の第5章を簡単に見てきました。Web開発者が理解する上で最も重要だと思う領域に焦点を当て、RESTが元のWebモデルをどのように記述しているかを伝えようとしました。私の意見では、統一インターフェースの概念はRESTの中で最も重要で興味深い側面であり、上記の利点の主な原因であるため、Web開発者にとって理解する上で役立ちます。
最後に、今日のほとんどのJSON APIを記述するのにRESTが不適切であることをご理解いただければ幸いです。