例えば、アプリが「画面を取得したい」といったレベル（粒度）でリクエストすれば、GotAPIがリクエストを対象デバイスに、デバイスが理解できる方法で伝える。外部デバイスがそれぞれの仕様で返すレスポンスは、GotAPIが受け取って、アプリが使える形で渡す（図3）。

画像をご覧いただくには会員登録が必要です

会員登録・ログイン

図3 GotAPIのアーキテクチャ（出典：デバイスWebAPIコンソーシアム）

　ちょっと専門的な言葉を使えば、GotAPIはGET、POST、PUT、DELETEメソッドを使えるごく一般的なRESTベースのAPIであり、それが返すレスポンスはWeb標準であるJSON（JavaScript Object Notation）形式だ。Web開発に慣れた人なら、外部デバイス利用のための開発で特別なノウハウを習得する必要がない。

共通機能はGotAPIとプラグイン開発用SDKが担当、個別機能は自由に拡張可能

　ただし、GotAPIはこの仕組みの基礎となるフレームワークを規定しているだけだ。実際の各デバイスとの連携に当たっては、機器個別（種類別）のインタフェースがいる。外部デバイスの通信仕様はバラバラであり、同一目的のデバイスでもベンダーは差別化のために独自機能を備えようとするはずだ。

　そのような違いを吸収するために、外部デバイスそれぞれの連携機能は「プラグイン」の形で用意する。プラグイン開発用の標準SDKが用意されるので標準機能はSDK上で規定でき、それ以外の固有機能を個別に規定しておけばよい。GotAPIは、プラグインを探索して自身に組み込む。プラグインは、標準SDK＋固有機能＋デバイス個別ライブラリで構成されることになる。

　さまざまなデバイス用のプラグインが用意されれば、同一目的のデバイスを使うアプリの連携部分は一度だけ作り、後はプラグインを替えるだけで同じプログラムを複数のデバイス用に使い回すことができる。デバイス固有機能の追加はプラグインの変更だけで対応できるので、デバイスの機能追加やバージョンアップなどの際の変更・拡張にも容易に対応できる。

　GotAPIとプラグインを含めた全体が「デバイスWebAPI」だ。開発者は「何をするか」だけプログラミングすればよく、後はデバイスWebAPIが引き受ける。プログラムの再利用性が高まり、開発効率が上がりコストも工期も短縮でき、新デバイスの開発や普及推進を支援する効果もありそうだ。

　図4にAndroidデバイス用のデバイスWebAPIのイメージを示す。

画像をご覧いただくには会員登録が必要です

会員登録・ログイン

図4 AndroidデバイスのデバイスWebAPIのイメージ（出典：NTTドコモ）

　デバイスWebAPIは、OSから見れば1つのアプリであり、実体はHTTPサーバと考えてよい。図に見るように、スマートフォンのアプリ（図はWebアプリを対象にするがネイティブアプリでも同様）は、一度デバイスWebAPI仮想サーバを経由してデバイスに接続することになる。

　デバイスWebAPI側で行う仕事をアプリ側では意識しなくてもよい。また、プラグインはアプリ側から直接インストールできるので、どのプラグインを選ぶかもユーザーは意識しないで済む。

　なお、iOSデバイス用にも基本的には同様の考え方で外部デバイス接続を可能にしている。ただし、最新版ではこれまでと異なる方法が必要だ。ともあれ、いずれは同様に利用できるようになりそうだ。