日報 #21 - RESTful APIことはじめ

今日はなんの枕もなしに、さっそく本題から。
RESTful APIのURL設計について。

さぁググってググってググりまくれ！
と言わんばかりにドキュメントあふれるRESTですが、
よくまとまっていそうで読みやすいのはこの辺。
http://d.hatena.ne.jp/cou929_la/20130121/1358776754
http://www.restapitutorial.com/resources.html
頭から読んでもいいしリファレンスとして読んでもいいと思います。

さて、この手のルールを策定する時、いっっつも気になるのは、
「このルールの限界ってどのへんだろう」ということです。
要はこのルールにあぶれる奴がどのあたりで出てきて、実際出てきたら、どうやって対処しよう、ということです。 ましてや自分の経験がない分野だったらひたすら不安になります。
フレームワークを選ぶときは、こういった観点が判断理由の中心に置かれたりします。
で、
RESTはどうざんしょ。

リソースという考え方、それを操作するという志向、
httpメソッドとDBのCRUDを対応させるアーキテクチャ、
それ故にSQLクエリ文のようにURLを設計できるシンプルさ。
なんだかよさそうだ。

だが、URLを単純なディレクトリ構造に当てはめる発想からはやはり少しずれる。
もうはるか昔、index.htmlがあって、book/index.htmlがあったあの時代、
そこからindex.phpがディスパッチャになってクラスメソッドと対応したこの時代、
そのいずれとも沿っていないように見えるREST。
具体的に困るのはこういうシーンだ。

よくあるcustomerリソースについて考えた時、
~/customer/123
これは123番でアイデンティファイされるcustomerリソースのレコードを抽出するイメージにピッタリだ。
では123番と321番を両方一度に取り出したい時はどうするざんしょ。
よくあるのはfilterという概念で、 ~/customer/123,321
とか
~/customer/?filter=123,321
とか。
はたしてコレはどうなのよ。
それともhttp://www.restapitutorial.com/resources.htmlにあるように、
GET http://www.example.com/users?filter="name::todd|city::denver|title::grand poobah”
こうせよと？
WHERE文のようにやれと？

なんかイマイチぴんとこない。
リソースと、それを一意に特定する条件の付与という徹底さを追加するまではいいとして、
でも本来ディレクトリ名であったスラッシュとスラッシュの間部分に、カンマ区切りの文字列が現れるのはさすがに気味が悪い。これは僕が古い人間だからというのもあるが、、、
じゃぁURLをやめてGETクエリで、となるのだが、
GETクエリにカンマ区切り文字列、、、うぅむ、、、key,value構造をもっているのにカンマ区切り、、、
むぅ
となってまた明日になるのをひっそりと待つ夜更けです。