新しいウェブAPIを学ばなければならない時の労力は大変なものだ。しかもその努力の大半は同じ異なるAPIから取得できる同じオブジェクトのフォーマットに互換性がないことに対処するのに費やされる。ThoughtWorksのDuncan Cragg氏は'Object Network'というプロジェクトで、共通のデータ定義とアクセスフォーマットを通じてこの学習曲線を取り除こうとしている。そして、なによりも重要なのはこの試みによって生まれたグローバルに繋がったデータ構造が、ネットワーク効果を増幅することだ。InfoQはDuncan Cragg氏にこのプロジェクトの詳細や活動動機、APIの開発者がこのデータネットワークからデータを出し入れする方法について話を聞いた。
InfoQ:Object Networkとは何ですか。
馬鹿らしいほと明らかで提案されても却下しにくいにも関わらず、誰もが実現できないと思っていることのひとつです。
ProgrammableWebに掲載されている4000ものAPIはすべて互換性がありません。このような様々なサイトやサービスのAPIを使う代わりに、ひとつの方法でデータを利用できれば便利ではないでしょうか。Twitter、Facebook、Flickr、Googleはそれぞれユーザのデータや写真を持っています。なぜ4つの別々の方法でアクセスし、4つの互換性のないフォーマットでデータを受け取らなければならないのでしょう。ひとつの方式、ひとつのフォーマットを定義すれば、4つではなくひとつのクライアントライブラリを書くだけで済むはずです。
APIの増加は目を見張る勢いです。では、90年代のウェブの普及と比べればどうでしょう。私が思うに、いくつかの単純で基本的なプロトコルとフォーマットを定義できれば、90年代のウェブと同様の爆発的なAPIの普及が達成できるでしょう。必要なのは'APIのためのHTML'です。つまり、JSONの検索の規約やJSONの形式についての定義が必要なのです。とてもシンプルな話です。
ここで登場するのがObject Networkです。
Object Networkにデータを発行するための仕様はシンプルです。HTTPとJSONに関する基本的な規約が決められており、連絡先やカレンダーイベント、ニュース、記事、メッセージ、メディアメタデータ、コメント、レビューなどの共通データのフォーマットも用意されています。
これらのパターンに従うだけでサイトのデータをグルーバルに繋がった'データ構造'に配信できます。サイトのデータを公開する以前から存在するクライアントやクライアントコードでデータにアクセスできます。
InfoQ: なぜObject Networkが必要なのでしょうか。
すべてのAPIがそれぞれ異なり、異なるプロトコルが必要で、違う方法でJSONを解析しなければなりません。しかし、私たちの業界は常に、コードを共有し共通の標準を確立することで効率性を追求しています。
サーバ側の開発者は、Object Networkにデータを発行できればデータをより広く公開することができます。クライアントコードは共通で各サイト間で連携しているからです。インターフェイスの設計に時間を費やす必要もなくなります。プロトコルのフォーマットや規約も実装するまでに既に文書化されているはずです。また、特別な事例や領域のために新しいObject Networkを定義することもできます。既存のデータや新しいデータをObject Networkに簡単に配信するためのフレームワークも現れるでしょう。
Object Networkのインターフェイスを使うクライアント側の開発者は共通のクライアントコードを再利用できます。このコードはリンクのフェッチやデータのキャッシュ、基本的なHTMLの規約などを制御します。また、共通のデータタイプを解釈し、連絡先の情報を地図に点描する関数など便利な関数を提供します。また、リンクを辿ることで更なるデータが得られます。
InfoQ: Semantic WebやLinked DataやRESTのハイパーメディア制約になく、Object Networkにはある特徴を教えてください。
ほとんどの開発者は複雑すぎたり、大変な労力をかけなければならないことを学習したりする時間を持っていません。したがって、Semantic WebやLinked Dataや一風変わったRESTのパターンなどは開発者から忌避されます。
私はRDFがデータの公開に適していると考えているAPIの開発者を知りません。RSS 1.0はデータポイントとして働きます。JSON-LDは正しい方向へ進み始めているのかもしれませんが、Semantic Webの重荷を背負い過ぎるでしょう。HTTPの使い方やRESTfulなアプリケーションの周辺では規約が作られそうにありません。データ更新関連も同様です。
同様に、私は平均的な開発者が正確なRESTに注意を払っているとは思いません。RESTを適切に扱うのが簡単なら、いわゆる'REST API'は実際にRESTfulなはずです。
開発者にはもっと単純なパターンが必要です。簡単に扱えて、Semantic Webの利点を享受できて、RESTの相互運用性とスケーラビリィティも備えるパターンです。
データシンプルなJSON形式でSemantic Webにどうやって公開するか、ステートレスであることや自己記述型であるというようなRESTの制約をどのように満たすか。これらのことはほとんど誰も教えてくれません。
しかし、シンプルなJSONのテンプレートを使ってObject Networkにデータを公開する方法なら簡単に教えられます。オブジェクトの間にハイパーリンクを貼る方法やHTTPメッセージに何を記述するべきかについても教えられます。また、データ更新はObject Networkの言語の一部です。
Object Netwotkは本当にRESTfulかどうか、Linked Dataと比べてRESTfulかどうかについて言えば、私は本当にRESTfulだと思いますし、Linked Dataより優れていると思います。私は多くの人にObject Networkを使って話して欲しいし共有して欲しい、データを公開して欲しいと思っています。動的に結ばれたデータのネットワークに参画して欲しいのです。
Semantic WebやLinked Dataの情報や使われている語彙に多大な価値があるのは明らかです。これらの情報は静的な情報として、また、オブジェクトの型の意味としてObject Networkにも公開され再利用されます。rdf+xmlをObject NetworkのJSONに変換するのは理にかなった方法です。
同じようにいわゆる'REST API'は便利なデータを大量に提供します。これらのデータはすべて簡単にObject Networkで利用できます。ql.ioのようなツールを使えば簡単でしょう。
InfoQ: オブジェクトプログラミングモデルとObject Networkのデータモデルのミスマッチはどのように克服するつもりですか。
分散システムが一番上手く動作するのは、'分散している部分'がプロセスやプロシージャやメソッドの呼び出しではなく、ひとつのきちんとしたデータの塊である場合だということは広く知れ渡っていると思います。同様に非同期でステートレスで冪等性がある(同じメッセージを複数回繰り返しても問題ない)処理の方が、同期の脆いロックが必要な処理よりも管理しやすいです。
なので、Object NetworkにRMIのインターフェイスがないからと言って不平をたくさん言う人が出てくるとは思いません。
Object NetworkのオブジェクトとはJSONの'O'です。簡単に言えばシリアライズされたハッシュテーブルです。JSON DTOに似ているかもしれませんが、厳密なフォーマットがあり、型の構造、URL、他のオブジェクトへリンクするコンテンツを持っています。
Object Networkのオブジェクトはサーバによって'公開された状態を与えられた'ものだと考えられます。
オブジェクトはスプレットシートのように状態に依存して動作します。'このオブジェクトの状態はあのオブジェクトの状態に依存する'というようなことです。オブジェクトこの点についての詳細とプログラミングモデル('関数型オブザーバ'や'FOREST'と呼んでいます)については以前'REST: From Research to Practice'という本に書きました(http://forest-roa.orgもご覧ください。古い資料ではObject Networkではなく'Object Web'と記載しているのでご注意を)。
でも全体を理解しなくてもかまいません。Object Networkのインターフェイスを使えばオブジェクトに命を吹き込めるのです。今は最も単純なパターンを説明しています。より理解が深まったら上述の資料に目を通してください。
InfoQ: Object Networkの現在の状況と次の一手を教えてください。
今まではThoughtWorksの顧客や同僚だけが関わってきましたが、現在のObject Networkのブログの記事は外部からも注目を集めています。また、私はこのアイディアについて定期的に引き続き記事を書いたり講演をしたりするつもりです(何度か名前を変えましたが、プロジェクトが進んできましたので、今後は'Object Network'という名前に決定です)。
ブラウザクライアントのJavascriptのコードがGitHubにアップされています。これはObject Networkのビューワです。これを使えば互いに繋がっているオブジェクトを辿り、ポーリングしたりリフレッシュすることでデータの変更を検出できます。また、オブジェクトの型を識別できるので、地図上の連絡先を見る機能なども持っています。また、このビューワをJavascriptのライブラリとして公開し、Object Networkのデータを利用するアプリケーションで再利用できるようにするつもりです。Node.js上で動作するようにする必要もあります。
Android向けのObject Networkビューワでありサーバでもある'NetMash'のJavaのコードもGitHubにありますが、現時点では実験的な試みです。このコードには非同期で双方向でデータを更新する仕組みに関して先進的な特徴を備えています。
InfoQ:Object Networkに関わるにはどうすればいいですか。
(1) Google Groupに参加し、(2) ブログを読んでください。
そしてObject Networkに参加してください。とても簡単です。既存のウェブの仕組みとJSONのテンプレートを使えばいいのです。静的なJSONファイルや事前に生成したJSONファイルでもかまいません。ます、公開する必要があるので、既に公開されているものの利用しにくい形式のデータです。公開を簡単にするためにはサーバサイドのフレームワークやライブラリのサポートが必要かもしれません。
公開したデータはすべてJavascriptのビューワで確認できます。また、Javascriptのライブラリのコードを参考にして独自のアプリケーションを作成するのもいいでしょう。もちろん、コーディングを手伝ってくれるJavascriptの専門家は大歓迎です。