ただのにっき

■ おれだったらフォト蔵APIをこうする(2)

昨日のエントリに対して、開発者の方からツッコミをいただいた。

Flickrにしろdel.icio.usにしろ本来の意味でのRESTになってないAPIが多く存在するのが現実です。

これはagree。とは言ったもののFlickrやdel.icio.usのAPIは軽く眺めたことがある程度なので、コメントは控える。AmazonやGoogleのような先駆的なベンダーがGETだけで済む取得系APIを公開して「これがRESTでござい」とやっちゃったのがいけなかったんじゃないかと、個人的には考えているのだが。

PUTやDELETEは開発者にとってもあまりなじみのない単語であり、GETやPOSTの方が分かりやすく、IEなどのwebブラウザだけでテストが行える利点があり、より多くの開発者を獲得できる可能性があります。

これもagree。たとえばRubyのNet::HTTPには、DELETEに対応したクラスがない。もしRESTfulなサービスがあったら、Deleteクラスを自作しなくてはならないだろう……と思ったけど、RAAにはRESTを実装したライブラリがあるみたいだなぁ。こんど使ってみよ。

しかしだからと言って、フォト蔵もRESTを名乗っていいということにはならないのではないか。標準化団体によって規約化されているわけではないものの、RESTはきちんと定義された概念だ。正しくないとわかっているのに、なぜRESTを名乗るのか。ここは開発者の良心を期待したいところである。

Web上でAPIを公開するのに、SOAPやREST、XML-RPCでなければならないという法はない。開発者が使いやすいと信じているなら、RESTなど名乗らずに独自方式であることを明記すればいいではないか。わざわざRESTに対する誤解を拡大させることはないと思うのだが、いかがだろうか。フォト蔵APIの概要から「フォト蔵APIは全てRESTで提供されています。」の一文を削除しても、何の問題もなく意味が通じると思う。

それはさておき、ほとんどのAPIはちゃんと呼べたんだけど、どうしてもphoto_addで写真が追加できない。エラーは「REGISTERATION_FAILURE: Failed to register 」なので原因もわからんし。photoパラメタの指定方法がいけないような気がするんだけど、バイナリをそのまま与えたらあかんのだろうか(もちろんURL encodeしてるけど)。

■ メールにメモがつけたい(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協会」を作って普及を促進してもらうとか。

■ wifehacks

ワイフハックとは(ichan::Weblog):

3. hack好きの旦那がハックと夫婦生活を両立させる

例: 細切れの時間を利用したロングテール型hack、温泉やプールでの着替え待ち、出先でのトイレ(化粧)待ちや週末の早起き、調理中などに素早く開発したり読書したりする。

「ロングテール型hack」という表現は2.0っぽくてイイ!と思った。おれもそれを狙って、この冬はコタツにノートPCを持ち込む習慣にしているのだが、かみさんと会話をしながらとか、TVを見ながらhackをするのは至難の業。やっぱ集中できないとダメみたい。

つーかそもそも、こうしてコタツでPCに向かっているおれは今、一人なわけだが。かみさんはリビングから離れたデスクでmixiに夢中。