RESTfulアーキテクチャは「考え方」。これに始まりこれに戻る。
開発したシステムがRESTのいくつかの特徴に当てはまっても、考え方が違ってたらそれはRESTfulではない。たとえば、最初からページ指向に作ってきたアプリに、見たところそれらしいURLを最後に付与してみたとしても、RESTfulな精神に従ってないなら、RESTfulと呼べない(かもしれない)。
逆に、システムの設計思想が基本的にRESTfulな考え方(RESTfulな考え方の各段階）にしたがっていたなら、それはシステムのいくつかの特徴がRESTfulと反するものであっても、依然としてRESTfulでありうる。たとえば、（何らかの現実的制約により）直感的なＵＲＬにはなっていなかったとしても、RESTful な精神を生かしていると言い得る。
ではその考え方とは何か。思うに、以下の「順序」で考えることも重要なのではないかと。
なお本記事は一切参考文献とか見ないで
勉強会で聞いて考えたことだけを基にし
て書いてるのでよろ。こんなところに
公開すんなって話だが自分用のメモな
ので良しとする。
●ＲＥＳＴ第０原則
はじめにリソースありき。システムにおいて処理の対象となり、かつユーザからも認識可能な情報（つまり内部情報ではないもの）をリソースと呼んでみる。それをＵＲＬできれいに階層分類できるものとする。
●ＲＥＳＴ第１原則
システムの動作は、それらのリソースに対するＣＲＵＤ操作に還元できるものと整理する。またそのように実装する。
●ＲＥＳＴ附則Ａ
リソースをあらわすＵＲＬをクライアント側からも見えるようにする。そのＵＲＬを指定するということを、なるべく隠さない。(ここら辺になってくると「原則」というほどでもない。要件によっては破っても別にいい）
●ＲＥＳＴ附則Ｂ
システム実行上必要な「状態」というもののうち、サーバクライアントの両側で同期的に保持管理しなければならないものを、「現在アクセス中のリソースのＵＲＬ」だけにとどめたいと願う。それだけに集約できればうれしいと感じ、それが達成できれば幸福だと信じる。（それができない場合、それは必要悪なのだ、最後の審判の後では消えてなくなるものだと位置づけるが、特には排除もしない。）
- その例としてはたとえば認証情報など。これはＡＯＰなのだ、クロスカッティングコンサーンなんだ透過的なんだとして、設計的にあるいは実装的に「見えなく（分ける・隠す）」する。
●ＲＥＳＴ附則Ｃ−Ｚ
だんだん後ろに行くにつれぐだぐだになっていく附則（ＰＵＴがどーしたとかURIがどーのとか）をここに列挙したいのだが残念ながらこの余白は狭すぎる。
で、RESTなんていう名前が悪い。（こればっか）
「リソース指向設計」と呼んでいいんじゃないかのう。
