Gomizonを見てshinGETsuAPIを思う
動作 → Amazon のマーケットプレイスにある商品(中古本)を Tropy 式に扱う
つまりRandomボタンを押す度に中古本が表示されるという仕組み。 UIは面白いんだけど、裏に一工夫あったらもっといいかも。 Randomの代わりに「興味あり」「興味なし」の2ボタンがあり、 ユーザの嗜好にあった本を優先表示するとか。
TropyのUIで裏方には意味(セマンティクス)を利用した一工夫というのは 元祖Tropyについての言及で見たような気がするんだけど、 場所を思い出せません。
さて、Gomizonが使ってるのがAmazon ECSというAPIで、 Google Maps や Skype にも API があります。 新月でもAPI方式を採用すべきなのか、 ちょっと考えてみました。
新月の場合はプロトコルが(曖昧ではありますが)公開されていますので、 例えば2chブラウザのような新月ブラウザを作ろうとすれば、 新月ブラウザに新月本体の機能を持たせることができます。 Skypeはプロトコルが非公開なので、その機能を使うには 外部のプログラムがAPIを使ってSkype本体を操作する、という形になります。 新月の場合もAPIを作れば新月ブラウザは表示機能だけ持っていればよく、 通信関係は全てAPI経由で新月本体にやらせればよい、ということになります。
選択肢は多い方がよいので、APIを用意するのはよいことだ、というのは確かです。 しかし開発側としてはプロトコルの管理だけでなく APIも管理しなければならないのはしんどいです。
ここでいうAPIはHTTPを利用したものについての話なんですが、 朔では Pythonで書かれたライブラリの機能を直接呼びだして使うこともできて、 これも(仕様を固定すれば)一種のAPIと呼べるでしょう。 この話はPerl版のときにCrescent作者氏と話したこともあります。