RESTには3つの意味がある。
- Roy Fieldingによって提唱されたアーキテクチャスタイル
- 原論文 https://www.ics.uci.edu/~fielding/pubs/dissertation/top.htm
- Mr. Fieldingのブログ http://roy.gbiv.com/untangled/2008/rest-apis-must-be-hypertext-driven
- 解説記事 https://xtech.nikkei.com/atcl/nxt/column/18/00138/092100882/
- 必要条件の一つにHATEOAS（ヘイタスなどと発音される。レスポンスに関連するリソースのURLを含めるという規約）があり、世の中のAPIのほとんどはそれを満たしていないので、この意味のRESTと言えない
- 複雑なSOAPに対抗して提唱された、より軽量なAPIのスタイル
- 現在はSOAPが死滅したため、この意味で使われることは稀
- Rails等のフレームワークによって広められた、CRUD操作をHTTPのメソッドに対応させるスタイル
- しかしこのスタイルも明文化されて広く合意されているものではない。人によって意見が異なることが多々ある
- Create = POST, Read = GET, Update = PUT（全体置換）/PATCH（部分更新）, Delete = DELETE
- 原則的に全てのAPIをリソースのCRUDに見立てるが、どうしてもCRUDに当てはまらない処理はPOSTを利用する
- 2024年現在、この意味で使われることが多い
- 例えば、ログインはセッションの作成に見立てPOST /sessionsとされるが、現実にはPOST /loginとされることもある。承認はPOST /approveなどとなる。同期するAPIは冪等なのでPUTのイメージがあるが、PUTはリソースの置き換えだけに利用されるものなのでPOSTを利用するという意見がある
- CRUDをメソッドに対応させるのは本来の（1の）RESTではない
- GET, HEAD, PUT, DELETEは冪等性が要求される。この冪等とはリソースが変わらないことを意味し、レスポンスは変わっても良い。例えば、DELETEの2回目は404になっても良い
- 冪等と安全に関する誤解 #API - Qiita
この記事では、60〜70人のエンジニアを面接して、誰一人RESTの定義を正しく答えられなかったと書かれている。
https://whizmodo.wordpress.com/2015/01/10/will-the-real-restful-api-please-stand-up/
この記事では、なぜRESTは宗教的になりがちなのか考察されている。要は一人の創始者があいまいかつわずかな言葉でお告げを語ってそれっきりになってしまったため、他の人による「解釈学」が発達しているということ。
http://mikeschinkel.com/blog/why-rest-is-more-like-religion-than-most-technologies/
RESTの6大規約（原論文のCHAPTER 5より）
- クライアント・サーバー（当然）
- ステートレス（クッキーやCSRF対策のトークンを入れるとステートフルになってしまう…）
- キャッシュ（サーバはレスポンスのキャッシュ可否を明示すべし）
- ユニフォームインターフェイス（これが重要。URL、HTTPメソッド、メディアタイプ）
- レイヤー（OSI参照モデルのように？レイヤー構成にすべし）
- コード・オン・デマンド（クライアントサイドスクリプト）
リチャードソンによるマチュリティモデル（RESTの4段階モデル）とマーティン・ファウラーによる解説。マーティン・ファウラーの説明は分かりやすい。
http://martinfowler.com/articles/richardsonMaturityModel.html
http://www.crummy.com/writing/speaking/2008-QCon/act3.html
Level 0 Plain Old XML（昔ながらの単純にXMLを返すやり方）
Level 1 URLでリソースを表すようにする（リソースを動詞でなく名詞で表す）
Level 2 HTTPメソッドGET, POST, PUT, DELETE等を正しく使い分ける
Level 3 レスポンスの中に関連するリンクを含める
