読者です 読者をやめる 読者になる 読者になる

uehaj's blog

Grな日々 - GroovyとかGrailsとかElmとかRustとかHaskellとかFregeとかJavaとか -

社内のREST勉強会に出て考えたこと

RESTfulアーキテクチャは「考え方」。これに始まりこれに戻る。

開発したシステムがRESTのいくつかの特徴に当てはまっても、考え方が違ってたらそれはRESTfulではない。たとえば、最初からページ指向に作ってきたアプリに、見たところそれらしいURLを最後に付与してみたとしても、RESTfulな精神に従ってないなら、RESTfulと呼べない(かもしれない)。

逆に、システムの設計思想が基本的にRESTfulな考え方(RESTfulな考え方の各段階)にしたがっていたなら、それはシステムのいくつかの特徴がRESTfulと反するものであっても、依然としてRESTfulでありうる。たとえば、(何らかの現実的制約により)直感的なURLにはなっていなかったとしても、RESTful な精神を生かしていると言い得る。

ではその考え方とは何か。思うに、以下の「順序」で考えることも重要なのではないかと。

なお本記事は一切参考文献とか見ないで
勉強会で聞いて考えたことだけを基にし
て書いてるのでよろ。こんなところに
公開すんなって話だが自分用のメモな
ので良しとする。

●REST第0原則

はじめにリソースありき。システムにおいて処理の対象となり、かつユーザからも認識可能な情報(つまり内部情報ではないもの)をリソースと呼んでみる。それをURLできれいに階層分類できるものとする。

●REST第1原則

システムの動作は、それらのリソースに対するCRUD操作に還元できるものと整理する。またそのように実装する。

●REST附則A

 リソースをあらわすURLをクライアント側からも見えるようにする。そのURLを指定するということを、なるべく隠さない。(ここら辺になってくると「原則」というほどでもない。要件によっては破っても別にいい)

●REST附則B

システム実行上必要な「状態」というもののうち、サーバクライアントの両側で同期的に保持管理しなければならないものを、「現在アクセス中のリソースのURL」だけにとどめたいと願う。それだけに集約できればうれしいと感じ、それが達成できれば幸福だと信じる。(それができない場合、それは必要悪なのだ、最後の審判の後では消えてなくなるものだと位置づけるが、特には排除もしない。)

- その例としてはたとえば認証情報など。これはAOPなのだ、クロスカッティングコンサーンなんだ透過的なんだとして、設計的にあるいは実装的に「見えなく(分ける・隠す)」する。

●REST附則C−Z

だんだん後ろに行くにつれぐだぐだになっていく附則(PUTがどーしたとかURIがどーのとか)をここに列挙したいのだが残念ながらこの余白は狭すぎる。

で、RESTなんていう名前が悪い。(こればっか)
「リソース指向設計」と呼んでいいんじゃないかのう。

広告を非表示にする