RESTとは
REST（Representational State Transfer／レプレゼンテーショナル・ステート・トランスファー／レスト）は、HTTPの資源と操作を活用してAPIを設計するアーキテクチャ上の考え方です。元来は、分散hypermediaシステムへ一組の制約を適用して得るアーキテクチャースタイルとして示されました。
中心にあるのは、リソースを識別し、その時点の状態を表現として交換し、リンクをたどって次の操作へ進む考え方です。HTTPとURLは実現に適した仕組みですが、HTTPを使うだけで自動的にRESTになるわけではありません。
RESTは「URLへJSONをPOSTする書式」の名前ではありません。クライアント／サーバー、ステートレス、キャッシュ、一様インターフェース、階層化システムなどの制約を組み合わせた設計です。
RESTを形作る制約
UIとデータ管理を分離し、それぞれを独立して進化させやすくします。
各要求が理解に必要な情報を持ち、サーバーはクライアントセッション文脈へ依存しません。
応答を再利用できれば遅延とサーバー負荷を減らせます。
リソース識別、表現による操作、自己記述メッセージ、hypermediaを揃えます。
クライアントは接続相手がオリジンかキャッシュ・ゲートウェイかを意識せず同じインターフェースを使います。
クライアント機能をダウンロードコードで拡張する任意制約で、唯一optionalです。
リソースと表現
リソースは利用者、商品、注文、画像、検索結果のように識別して扱う対象です。リソースそのものと、ネットワークで交換するJSON・HTML・画像等の表現を分けます。
同じリソースでも言語、メディアタイプ、時刻、権限で表現が変わり得ます。URLはリソース識別に使い、データベースの表名や内部ファイルパスをそのまま公開する必要はありません。
一様インターフェースの四要素
Fieldingの説明では、リソースの識別、表現を通したリソース操作、自己記述的メッセージ、アプリケーション状態を動かすエンジンとしてのhypermediaが一様インターフェースを構成します。
HTTPでは方式、状態、ヘッダー、メディアタイプ、キャッシュディレクティブ、リンク等を共通の意味で使います。エンドポイントごとに同じ方式が別の独自命令を意味すると、中間層とクライアントがメッセージを一般的に理解しにくくなります。
HTTP方式と安全性
GETは取得、POSTはリソースへの処理依頼や作成、PUTは指定リソースの置換、PATCHは部分変更、DELETEは削除に使われるのが一般的です。ただし実際の意味はAPI契約で確認します。
安全は利用者が要求した状態変更を意図しない性質、冪等は同じ要求を複数回行っても意図した結果が一回と同じになる性質です。GETは通常安全かつ冪等、PUT・DELETEは冪等、POSTは一般にどちらとも限りません。
ステートレスの意味
ステートレスは「サーバーにデータベースを置かない」「ログインできない」という意味ではありません。リソース状態はサーバーに保存できます。各要求の理解に必要なクライアント文脈を、サーバー側の暗黙セッションへ依存させないという制約です。
認証情報や要求パラメーターを毎回送れば、別インスタンスが同じ要求を処理しやすくなります。一方でトークン、キャッシュ、データベース等の共有状態は存在するため、システム全体が無状態になるわけではありません。
cacheable応答
応答はキャッシュ可能か不可能かを明示します。適切なキャッシュは遅延、帯域幅、オリジン負荷を減らしますが、プライベートデータや更新直後の表現を誤って共有しない設計が必要です。
方式、状態、Cache-Control、Vary、検証器等を使い、クライアント・共有キャッシュ・CDNが同じ規則で判断できるようにします。
階層化システム
逆プロキシ、ゲートウェイ、キャッシュ、負荷分散装置、セキュリティフィルターをクライアントとオリジンの間に置けます。各層が一様メッセージを理解できれば、オリジン変更をクライアントへ露出せず拡張できます。
ただし中間層が認証ヘッダーを落とす、キャッシュ鍵を誤る、状態を書き換えると意味が崩れます。エンドツーエンドの契約試験が必要です。
hypermediaとリンク
RESTでは、受け取った表現内のリンクや制御から次に可能な操作を発見する考え方が重要です。クライアントがすべてのURL構造を外部文書から固定して組み立てるほど、サーバー変更との結合が強くなります。
実務で「REST API」と呼ばれるものにはhypermediaを限定的にしか使わない設計も多く、RESTらしさには幅があります。名称より、どの制約を満たし何を得たいかを明示します。
RESTとRPCを分ける
RPCはリモート側のprocedureを呼ぶモデルで、動詞名の操作とパラメーターを中心に設計します。RESTはリソースと表現、一様インターフェースを中心にします。どちらが常に優れているのではなく、システムの性質とtoolingで選びます。
HTTP上でRPCを行うこともできます。その場合「HTTP API」ではあっても、RESTの全制約を満たすとは限りません。
RESTはリソースの表現を一様インターフェースで交換し、自己完結した要求、キャッシュ、中間層、リンクによる遷移を可能にするアーキテクチャースタイルです。HTTPやJSONという部品名だけで判定しません。
RESTの導出、制約、resource・representation・uniform interface：Roy T. Fielding, Architectural Styles and the Design of Network-based Software Architectures, Chapter 5