2006-03-01(水) [長年日記]
■ メールにメモがつけたい(4)
せっかくパッチをもらったのに、昨日は忙しくて試せなかった。先ほど導入。ばっちり直りました。感謝。もっとも、これだとせっかくテキストファイルになっているのに、エディタでそのままいじれなくなっちゃうね……まぁいいか。
ついでに、拡張機能(.xpi)がどんな風に作られているのかも(今ごろ)知った。ロジックはJavaScriptなんだねぇ。てっきりXMLを使った独自言語だと思いこんでたよ(←XULを何かひどいものだと信じていたらしい)。アプリケーションの組み込みスクリプトも、最近はJavaScriptがかなり手堅い位置を占めるようになってきたなぁ。(MacOSの)DashboardやYahoo! Widgetsもそうだよね、たしか。
■ Apple新製品
iPod Hi-Fi、ダセぇ。これがApple製品だなんて信じらんない。他社製品が間違って紛れ込んだんじゃないのか。
Mac miniは、相変わらずちょっと欲しい。やはり小さい機械には惹かれる。これでWindowsが動けばなぁ(←だいなし)。
■ おれだったらフォト蔵APIをこうする
せっかくユーザでもあるので(携帯のバックアップにしか使ってないけど)、β公開されたフォト蔵API(アナウンス)を使ってみることにした……んだけど、概要を読んで「ちょっと待て」と思った。
フォト蔵APIは全てRESTで提供されています。機能毎の個別のURLに対して必要なデータをPOSTします。結果は全てXMLで返ってきます。
えーと、GETを使うべきAPIでもPOSTですかね。それ、RESTじゃなくてただの「なんちゃってRPC」だし。……とは言ったものの、自分だってRESTを理解しているかどうか怪しいもんだ。恥をかくつもりで自説を開陳しちゃった方が楽になれそうなので、書いてしまおう。
RESTは、あるリソースをHTTPのメソッドを使って操作するという「作法」だ(カッコつけて「アーキテクチャ」と呼んだりする)。リソースは特定のURIで表現され、それに対してPOSTでデータの追加、GETで取得、PUTで置換、DELETEで削除を行う。
たとえば写真(photo)を操作するAPIをREST思想のもとで設計するなら、URIは「写真」そのものをイメージする「.../api/photo」にする(名詞であることが重要)。このURIに対して、
- 写真データをPOSTすると写真が投稿され(IDが返る)
- IDを指定してGETすると写真が取得でき
- IDを指定した上で写真データをPUTするとIDの写真が置き換わり
- IDを指定してDELETEすると削除される
という風にする。特にGETはクエリも含めて特定の写真を指し示すURIになるという点が重要。
アルバム操作も同様で、「.../api/album」というURIに、POSTで作成、GETで写真一覧、PUTで名前変更、DELETEで削除できるような設計をする。
現状のフォト蔵APIは、「.../api/photo_add」のようにURIがすでに機能を表現してしまっている(名詞でなく動詞になっている)。このURIは名前からして写真の追加にしか使えない。だからPOSTだけでも事足りてしまうのだが、これではもはやRESTは名乗れまい。
おまけにphoto_albumやuser_groupのような、本来GETで扱うべきAPIまでPOSTで操作する仕様。ちなみにこの2つのAPIを試しにGETで操作してみたら動いてしまった。そもそも内部でメソッドの区別をしていないようだ。
著名なWebサービスでも、PUTやDELETEまで駆使したフル装備なAPIを提供しているところは少ないので、こういう「俺REST」がはびこる一因になっているような気がする。REST陣営(って誰?)は、コンソーシアムでも作って作法を標準化した方がいいんじゃない? 総務省に「日本REST協会」を作って普及を促進してもらうとか。
Appale :-(
「天晴れ」ってシャレたいのかと思ったけどたぶん違う。
トホホ。直しました。
ご意見まことにありがとうございます。
たださんのおっしゃることはもっともだと思います。
ただ、Flickrにしろdel.icio.usにしろ本来の意味でのRESTになってないAPIが多く存在するのが現実です。
PUTやDELETEは開発者にとってもあまりなじみのない単語であり、GETやPOSTの方が分かりやすく、IEなどのwebブラウザだけでテストが行える利点があり、より多くの開発者を獲得できる可能性があります。
GETでもPOSTでも、どちらでも動作するように作っています。さすがに写真データをGETで受け取るわけにはいきませんが。この辺はマニュアルの不備です。近いうちに修正しておきます。
http://sho.tdiary.net/20060302.html#p01
ただのにっき
おれだったらフォト蔵APIをこうする(2)
昨日のエントリに対して、開発者の方からツッコミをいただいた。 Flickrにしろdel.icio.usにしろ本来の意味でのRESTになってないAPIが多く存在するのが現実です。 これはagree。とは言ったもののFlickrやdel.icio.usのAPIは軽く眺めたことがある程度なので、コメントは控..
＞それに対してPOSTでデータの追加、GETで取得、PUTで置換、DELETEで削除を行う。
違うと思います。RESTの原論文では、具体的なメソッドについては触れていないはず。ためしに以下の論文で「POST」とか「PUT」とかで検索してみてください。
http://www.ics.uci.edu/~fielding/pubs/dissertation/top.htm
個人的には、とにかくGETが重要で、(cacheもできない)それ以外のものはそれほど重要ではない、と思っています。
あと、RESTは「アーキテクチャ」じゃなくて「アーキテクチャスタイル」です。つまり特定のアーキテクチャに縛られない、もうちょっと抽象的なものです。「PUT/GET/POST/DELETE」を絶対視するようになれば、それはアーキテクチャスタイルではなくアーキテクチャ（の1つ）でしょう。
具体的なメソッドに触れていないのは、それはRFCで定められていて自明だから触れていないだけではないのでしょうか？
RFCからすれば、HTTPにおいて
> それに対してPOSTでデータの追加、GETで取得、PUTで置換、DELETEで削除を行う。
は正しいですし、HTTPを本来の使い方で使う、というのがRESTの思想には含まれているはずですので、「絶対視」というわけではなく、HTTPの定義からすればごく自然なことなのではないでしょうか。
たしかに、たかはしさんの示すURLにはGETしか出てきてませんが、それは単にリソースの状態を取得するためによく使われる、と書かれているだけであって、重要であるとは読み取れませんでした。
逆にGETやPOSTの濫用はRESTではない、とyo-heiさんも指摘してますし。
http://yohei-y.blogspot.com/2005/05/rest-8-rest.html
合わせてこちらを読まれることもお勧めします。（既に読まれているとは思いますが。）
http://yohei-y.blogspot.com/2005/04/rest-5-get-post-put-delete.html
> あと、RESTは「アーキテクチャ」じゃなくて「アーキテクチャスタイル」です。つまり特定のアーキテクチャに縛られない、もうちょっと抽象的なものです。
それを言ってしまえば、たかはしさんが「GET重要」とおっしゃっているのも、アーキテクチャスタイルではなく、アーキテクチャの話ですよね。
ここでたださんが言っているRESTというのは、正確には「RESTアーキテクチャスタイルのアーキテクチャであるHTTPを利用したAPI」のことだと思われますので、アーキテクチャの話に絞って問題ないかと思います。
そしてたださんが指摘しているのは、RESTスタイルであるHTTPを、正しくREST的な使いかをしていないにも関わらず、それをRESTだと呼んでいることが問題だ、ということで、自分もこれには激しく同意です。
mizzyさんに言いたいことをすべて言われてしまった……。なお、私のRESTに関する知識は、もっぱらyohei-yさんのblogからです。
自分でも用語を意識的/無意識にボカして書いているのは反省すべき点だと思いました。このへんの整理は今日は時間がないのでいずれ。
AtomPPの普及が正しいREST API普及につながるのではないかなー、と考えてたりします。そのために早く仕様固まって欲しいのですが。