- 要はWebサービスを作るときのURL、ヘッダ、レスポンスの
規約ガイドライン - ガイドラインなので、縛りを加えるものである。RESTにしたからといって今まで出来なかったことができるようになるわけではない
- 変数名をキャメルケースにするかスネークケースにするかのようなもので、統一することにメリットがある
- ステートレス云々言ってるのは無視。定義が明確でないので、これはステートかと考えるのは時間を浪費するだけ。普通のWebアプリのお作法で作っていれば何も問題はない
- HATEOAS（ヘイタスなどと発音される。レスポンスに関連するリソースのURLを含めるという規約）はレスポンスのデータサイズが大きくなる上に、活用されることはめったにない。
- おそらく世の中のウェブサイトの99%はRESTなんて意識しないで作られている
- 思想もしくは宗教と化している部分がある。メリット・デメリットで判断するのでなく、教条的にRESTが正しいと主張されることがある
- 実際、英語でREST信者のことをRESTafarianというらしい
- 英語でググるときは「pragmatic restful」とキーワードにpragmaticを含めると教条的でないページが見つかる
- 最初の提唱者はRoy T. Fielding。2000年の博士論文
Roy T. Fieldingのブログ
http://roy.gbiv.com/untangled/2008/rest-apis-must-be-hypertext-driven
その論文
https://www.ics.uci.edu/~fielding/pubs/dissertation/top.htm
ブログで世間のREST APIがRESTじゃないと文句言ってるが、コメント欄でhypertextとは何かと聞かれているように、自分が用語を明晰に定義しないのが悪い。
この記事でも、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 レスポンスの中に関連するリンクを含める
Level 3まで実現しているAPIは少ないはず。FieldingによればLevel 3はRESTの必要条件であり、十分条件というわけではない。
URLを名詞にする理由は、HTTPのメソッド（GET, POST, PUT, DELETEなど）が動詞を表し、URLはその対象となるリソースだからということらしい。一方、マイクロソフトはPowerShellのコマンドとして使用を承認している数十個の動詞のリストを公開している。
https://msdn.microsoft.com/en-us/library/ms714428(v=vs.85).aspx
英語の動詞の中からプログラミング用に厳選したとしてもこれぐらいは欲しい。それに対してHTTPのメソッド数は少なすぎる。そもそもHTTPというプロトコルレベルのメソッドと、Webアプリケーションの処理内容を表すURLではレイヤーが違う。
RESTには有用な面もあるが、しばしば概念が抽象に飛躍しすぎ、そのためバズワード化している部分もある。
RESTに関する比較的
There is No REST API : programming