ただのにっき

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