福冨諭の福冨論

RSSリーダーではこちらをどうぞ→https://feeds.feedburner.com/fuktommy

Gomizonを見てshinGETsuAPIを思う

Tropy + Amazon = Gomizonより:

動作 → Amazonマーケットプレイスにある商品(中古本)を Tropy 式に扱う

つまりRandomボタンを押す度に中古本が表示されるという仕組み。 UIは面白いんだけど、裏に一工夫あったらもっといいかも。 Randomの代わりに「興味あり」「興味なし」の2ボタンがあり、 ユーザの嗜好にあった本を優先表示するとか。

TropyのUIで裏方には意味(セマンティクス)を利用した一工夫というのは 元祖Tropyについての言及で見たような気がするんだけど、 場所を思い出せません。

さて、Gomizonが使ってるのがAmazon ECSというAPIで、 Google MapsSkype にも API があります。 新月でもAPI方式を採用すべきなのか、 ちょっと考えてみました。

新月の場合はプロトコルが(曖昧ではありますが)公開されていますので、 例えば2chブラウザのような新月ブラウザを作ろうとすれば、 新月ブラウザに新月本体の機能を持たせることができます。 Skypeプロトコルが非公開なので、その機能を使うには 外部のプログラムがAPIを使ってSkype本体を操作する、という形になります。 新月の場合もAPIを作れば新月ブラウザは表示機能だけ持っていればよく、 通信関係は全てAPI経由で新月本体にやらせればよい、ということになります。

選択肢は多い方がよいので、APIを用意するのはよいことだ、というのは確かです。 しかし開発側としてはプロトコルの管理だけでなく APIも管理しなければならないのはしんどいです。

ここでいうAPIはHTTPを利用したものについての話なんですが、 では Pythonで書かれたライブラリの機能を直接呼びだして使うこともできて、 これも(仕様を固定すれば)一種のAPIと呼べるでしょう。 この話はPerl版のときにCrescent作者氏と話したこともあります。