RESTのよくある間違い

１）HTTPを利用するだけでは十分じゃない

SOAPやXML-RPCなどで実現可能な問題をHTTPで行う事が可能。ただ、間違って使う場合もあって、実際はHTTPとは別の標準プロトコルがあったりする。２以降ではHTTPが乱用される場合について考えられている。

２）POST を乱用しない

POSTは柔軟でほぼ全ての問題を解決できる(実際SOAPではPOST-only)。ただ、他のGET/PUT/DELETEで十分だったりする事もあって、分解可能かどうかよく考える必要がある。POSTは「新しいURIが作成されるとき」だけ利用すべき。

３）URIの内部構造に依存しない

URIは「塊」として扱われるべきで、これを構成する部品に触られるような事態があってはいけない。大抵、クライアントはURIを塊として処理する。
…？AtomPPならURI固定でパラメータはXMLで渡して隠せってこと？クライアントがURIを組み立てる可能性を排除しようってことか？

４）URIにアクションを入れない

REST はプロトコルからのできるだけ多くの「アプリケーション規約」を排除することが狙い。GETクエリの"action=***"は危険だし、アプリケーション固有の規約。
３との関係もある。アクションがURIに含まれれば当然クライアントで変更しようという可能性(危険性)が生まれる。

５）サービスはめったにリソースではない

言葉の定義？株価で考えると、RESTでは『株価サービス』ではなく『「株価リソース」と「株価一覧」を提供するサービス』として設計される？

６）セッションは関係ない

全てのメッセージについてHTTP認証が自動的に行われる。利用するのはサービスではなくリソースだから『ログイン』という概念は必要ない。
どういうときに間違えるんだ？とにかくセッション全廃したらいいってこと？

７）プロプライエタリなオブジェクト ID を発明しない

独自のIDではなく、標準化されたURI(http URI)を利用する。URI(http URI)はリファレンスとデリファレンスという２つの方法で情報を関連づける事が出来る。
URIからデータの位置を参照(推測)して、データの位置からURIを逆参照(推測)する？

８）プロトコル独立を気にしない

RESTではHTTPだけを利用する。SOAPではどのプロトコル上でもトランスポート出来る様になっている。これがプロトコル独立。プロトコル独立での問題は、「リソースモデルを捨てる」という事。これによって、RESTとWebを捨てる事になってしまう。

全体的に見て、覚えておくべきことはメッセージングインターフェースを通したサービスではなく、REST が URI を通してリソースを公開するためのものであるということだ。

個別の間違い指摘はそれなりに噛み砕けるんだけど、まとまってくるとお手上げ。しっかりと全体図を理解しないと、影響する部分と言うかどこをどうまとめたらそう言えるのかが分からない。

AtomPPでRESTが実装されてる(言い方合ってる？)場合、メッセージXMLをエンドポイント＋リクエストURIごとに対応する(正しい)HTTP Method経由でリクエストする事になると思う。その場合、「URIを通して」っていうのは「エンドポイント＋リクエストURIを経由して」メッセージを流したらリソースを取得できるって事でいいのかな？それともURIがリソースを取得する命令(データがあるところとか)になる(URIとリソースが直接的に結びつく)ってこと？いや、URIにアクションを含めないって辺りを考えると前者かなと思うんだけど。uniform interfaceが『HTTP(GET/PUT/DELETE/POST)』で、URIが『ルートエンドポイント＋リクエストURI』で、命令は『XML(Atom)』って事でいいのかな(AtomPP)。

そもそも、URIがなんなのか分からない。一般的に言う「アドレス」はURLだってのは分かる。で、URLを拡張してURIっていうのが考えられたってのをどこかで目にした(多分HTMLのリファレンス本)。RFC3986とか言われてもいまいち(読めばいいんだけど)。多分、結局「ひとつながりの文字列」になると思うんだけど、違うのかな。AtomPPの場合、ルートエンドポイントとリクエストURIとの組み合わせがURIって事で正しい？そうするとURIには命令とかパラメータとかの情報は一切含まれないものって事になるよね？

折角貴重な講演を直で聞けたのに、結局何も分かってないらしい。まあ、何が分からないかが明確になっただけでも喜ばしい事ではあるけど。何を調べたらいいかがはっきりした訳だし。