APIとUIはともにIである

| コメント(5) | トラックバック(1)

こんなおいしそうな議論をしていたとは、さっき飯食ってたときはぜんぜん知らなかったな(苦笑)。アンテナが下がってる。

naoyaさんの文章を読んでいてふと疑問に感じたのが、APIというときのIと「インタフェース」と書いたときとで、それぞれ異なる意味で言葉を使っているように読めるってこと。miyagawaさんのエントリのタイトルが「API, UI as Commons」と2つのIを並列して書いているのと並べて読むと、そこんとこを深読みしちゃうなぁ。

Catalyst の View::JSON とかは渡したデータ構造が勝手に JSON になって Web API になりますよ、というものだけども、これだけだとまだ開発者は「どういう API を持たせて、どういうデータ構造を返して」というのを自分で考えないといけない。なのでインタフェースに制約が欲しい。

APIというのはアプリケーションに対してサービスが公開するプログラミング用のインターフェイスだ。ViewがJSONになったからってそれがサービスが公開するインターフェイスになっていなければ、それはapIではない。それは愛じゃない。

Google Data APIがAPIで、Atom PPはPPであることはただの言葉のあやじゃない。Atom PPはProtocolなんで、あれ単体じゃ何もできない。あれはサービスが公開するインターフェイスではない。Google Calendarが公開するのはAtom PPではなくてGoogle Calendar APIなんです。

Protocolの目的は、ものすごくおおげさにいうと世界観の構築だと思う。物事に対するある見方を共有できるもの同士を見つけあい、わかりあえるようにするための決まり。Atom PPはブログのようなものをその世界観で作られた箱庭の中で扱うための規約。だから物事をAtom PPの世界からはみ出してしまうような見方で見ているブログのようなものはAtom PPを採用できない。

Interfaceの目的は、箱庭の中にいるもの同士がコミュニケートするための口。世界観を共有したとしても、僕はチェコ語をしゃべる人とはコミュニケートできない。世界観を共有していない人とは、いくら日本語で話していても実は互いに通じていない。Atom PPという世界観を共有していても、だからって誰もがGoogle Calendar APIをしゃべるわけじゃない。APIはそのインターフェイスを通じて入出力するものと密に結合するもんだと思います。インターフェイスを共通化できれば話せる相手が広がるから僕らは英語を勉強するけれど、それでもやっぱり僕が話す英語(を通じて公開される意味)は僕というサービスと密に結合している。英語そのものはインターフェイスではない、ただの構造。僕が話す英語がが僕と周囲とのインターフェイスだ。

だからインターフェイスがドメインと密結合してしまうって問題じゃないんじゃないかなあ。LDRのハックが利用しているインターフェイスだって、フィード収集吐き出しっていうドメインと密結合している。あ、僕が言いたかったのは疎結合が問題を解決するみたいな時代はもう終わってるってことなんだね。違うか?よくわからなくなってきたから寝る。1時間書いててこれが結びかよ

トラックバック(1)

トラックバックURL: http://www.luckypines.com/cgi-bin/mt/bt-tm.cgi/821

このエントリで、ユビキタスコンピューティングのアーキテクチャはフラクタルなMVC... 続きを読む

コメント(5)

interface がクラスライブラリやメソッドシグネチャだとがっちり密結合すると思うんですが、AtomPP にのっかった Atom フィード/エントリだともっとゆるくなるんじゃないでしょうか。よくわからんカレンダータグがついているフィードでも検索結果やポッドキャストとして扱える、みたいな。

要するにセマンティクスの問題を長々と説明されたんですよね。密結合がどうのというのも含めて、このあたりの話はXML/SOAPで議論し尽くされた感もあります。セマンティクスに関しては、Tim BrayはBig Fiveの例を示して、また違った意見を述べているようです。私はこの意見に賛成です。APIとProtocolの意味の違いはそれほど重要ではないと思います。

> 要するにセマンティクスの問題を長々と説明されたんですよね。
いいえ。

> 密結合がどうのというのも含めて、このあたりの話はXML/SOAPで議論し尽くされた感もあります。
尽くされているのであれば要約していただけると助かります。SOAPはAtom PPと同じProtocolであるというのが僕の認識です。

> セマンティクスに関しては、Tim BrayはBig Fiveの例を示して、また違った意見を述べているようです。
Big Fiveの例とこのエントリでは問題にしている領域が異なっています。

Google様に「疎結合って、なんですか?」と聞いたら、こんな記事が一位に表示されました。

http://www.atmarkit.co.jp/fdotnet/opinion/yoshimatsu/onepoint03.html

世界観というあなたの言葉を使わせていただきますと、ATOMPPにはCollectionやServiceといった世界観があります。EntryはCollectionがないと登録できませんから、あらかじめその世界観を知っておく必要はあります。プロトコルはこのような事前条件などをネゴするために必要なもので、たしかにAPIとは違うものです。しかし、一方で、ATOMPPにはCRUDが定義されています。これはエンティティに対するAPIと言えるものだと思います。何がいいたいか・・。密結合の話と「API、プロトコル」の話は別であって、エンティティさえ決めることができれば、APIは疎で十分じゃないかなあ、ということ。例えば、「写真を登録するサービス」をAPIにするのではなく、「写真」というエンティティと「エンティティを登録する」サービスに分けて考えてみれば、前者をセマンティクスの問題に帰結できるし、後者はBigFiveで十分だという話になると思う。「写真」が「picture」と同じというのはプロトコルではなくてセマンティクスの範疇ですよね。ただ、「誰のものか」が入ってくるとGUIDといったまた別のやっかいな問題があることは承知しているのですが・・。
的外れでご理解できなくてもかまいません。あのYoheiさんがコメントされていたので釣られてしまっただけです。おじゃまさま。

コメントする

このブログ記事について

このページは、Fumiaki Yoshimatsuが2006年5月10日 01:19に書いたブログ記事です。

ひとつ前のブログ記事は「cronはめんどいが定期タスクは実行したいなあ」です。

次のブログ記事は「Goodbye my pastels badges」です。

最近のコンテンツはインデックスページで見られます。過去に書かれたものはアーカイブのページで見られます。