ただのにっき

■ 1日おき

今日は月1回の通院日だった。ここのところ調子はいいので、その旨を告げたら、主治医はニヤリと笑って「薬を減らしましょう」と言った。減らすって、今飲んでるのは毎朝1錠である。これ以上どう減らすのかと思ったら、「1日おきに飲んでください」だって。

そ、そんな難しいことできません……とは言えず(気が弱いので)、黙って受け取ってきたが、正直、ちゃんと1日おきに飲める自信はまったくない。最初は偶数日か奇数日に決めればいいと思ったが、大の月は31日(奇数日)の翌日も奇数日(1日)だからダメ。せめて年間の通算日をベースに考えないと。

というわけで、簡単なリマインダを書くことに。この投薬が1年以上続くことはありえないので、年またぎは考慮不要。朝起きたら携帯のメールをチェックする習慣があり、かつ毎朝薬を飲む習慣が身についているので、朝、飲んではいけない日にだけ携帯にメールが届くようにすればいい。飲むかどうかの判断をメールの文面から判断しなくていいように、飲むべき日にはメールしないのが「良きユーザインタフェース」というものである。

#!/bin/zsh
if [ $[`date +%j` % 2] = 0 ]; then
   echo | mail -s 'DO NOT TAKE A MEDICINE!' 携帯のアドレス
fi

これをcron.dailyにツッコんでおけばOK。最初rubyで素直に書いたら10行余りになったんだけど、ちょっと調べたらシェルスクリプトの方が短くなったのでこっちで。こんなけったいな条件式が書けるとは知らんかった。

■ 寿司

今日は耳の日ではなく結婚記念日なので、夜は近所の寿司屋へ。その後、かみさんの行きつけのソウルバーに寄ってソフトドリンクを2杯(笑)。

■ おれだったらフォト蔵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協会」を作って普及を促進してもらうとか。