11th December 2017 #api #dropbox #dropboxapi #go #java #oauth 今回はDropbox APIの認証・認可についてかいつまんでご紹介します。Dropbox APIの認証・認可はOAuth2を利用しています。公式SDKの実装サンプルなどを参考にJavaとGoでの実装例をもとに紹介していきます。
Dropbox APIの概要でもご紹介したとおり、実装前にはアプリケーションの登録が登録が必要です。登録がすんだらApp keyとApp Secretが得られますのでこれらを使いましょう。
Java
SDKにauthorizeというサンプルがありますのでこれを参考にすると良いでしょう。 一般的なOAuthの流れと比べて変わったところは特にありません。Dropbox SDK JavaのJavadocに簡単な流れがのっているのでこちらを引用してご紹介します。
// No Redirect Example
DbxRequestConfig requestConfig = new DbxRequestConfig("text-edit/0.1");
DbxAppInfo appInfo = DbxAppInfo.Reader.readFromFile("api.app");
DbxWebAuth auth = new DbxWebAuth(requestConfig, appInfo);
DbxWebAuth.Request authRequest = DbxWebAuth.newRequestBuilder()
.withNoRedirect()
.build();
String authorizeUrl = auth.authorize(authRequest);
System.out.println("1. Go to " + authorizeUrl);
System.out.println("2. Click \"Allow\" (you might have to log in first).");
System.out.println("3. Copy the authorization code.");
System.out.print("Enter the authorization code here: ");
String code = System.console().readLine();
if (code != null) {
code = code.trim();
DbxAuthFinish authFinish = webAuth.finishFromCode(code);
DbxClientV2 client = new DbxClientV2(requestConfig, authFinish.getAccessToken());
// APIを使った処理
}
この例ではApp Key・App Secretをファイルから読み込んでいます。api.appという名前で次のようなJSON形式ファイルを準備しておいてください。
{
"key" : "App keyと置き換え",
"secret" : "App secretと置き換え"
}
大まかな流れとしては次の通りです。
- 設定情報などを準備 (
DbxRequestConfig, DbxAppInfo) - リクエストを準備
- 認証URLを生成し、ユーザーに認可をもとめる
- コードを受け取りトークンを生成
DbxClientV2インスタンスを作成して各種APIコール
設定できるオプションとしては、DbxRequestConfigにはエラー時の再試行回数などがあります。
Go
個人的にGoで実装する際には非公式SDKのdropbox-sdk-go-unofficialを使っています。処理の流れは基本的にJavaでの実装と同じです。OAuth認証・認可処理自体はSDKとは関係なくgolang.org/x/oauth2を利用しています。
authCfg := &oauth2.Config{
ClientID: "App keyと置き換え",
ClientSecret: "App Secretと置き換え",
Scopes: []string{},
Endpoint: oauth2.Endpoint{
AuthURL: "https://www.dropbox.com/oauth2/authorize",
TokenURL: "https://api.dropboxapi.com/oauth2/token",
},
}
authorizeUrl := authCfg.AuthCodeURL(
"csrf-stateの文字列",
oauth2.SetAuthURLParam("response_type", "code"),
)
fmt.Println("1. Go to " + authorizeUrl);
fmt.Println("2. Click \"Allow\" (you might have to log in first).");
fmt.Println("3. Copy the authorization code.");
fmt.Print("Enter the authorization code here: ");
var code string
fmt.Scan(&code)
token, err := authCfg.Exchange(context.Background(), code)
if err == nil {
dropboxCfg := dropbox.Config{
Token: token.AccessToken,
}
client := files.New(dropboxCfg)
// ...
}
認証時のロール
ちょっと変わったところとしてはリクエストを準備する際のロールについて紹介しておこうと思います。OAuthではscopesというパラメータを使ってアプリケーションに対し、認可する範囲を設定します。DropboxではDropbox APIの概要にてご紹介したとおり、アプリケーション登録時にアクセス権限を設定します。
このため、scopesパラメータを使わない場合も多いのですが一つだけ指定できるものがあります。
Dropboxでは個人向けDropbox (Dropbox Basic、Plus、Professional)アカウントと、Dropbox Businessアカウントをリンクすることでパソコン、スマートフォン、タブレットなどのアプリケーションで同時に二つのアカウントを利用できる機能があります。
このときに、アプリケーションの接続を会社のアカウントのみに限定したいとか、逆に個人向けのみに限定したいといった指定にscopesパラメータを利用します。
Javaの場合はDbxWebAuth.Request.Builderで withRequireRole()メソッドへROLE_PERSONALまたはROLE_WORKを指定します。
トークンの無効化
一定の処理が終わって、ログアウトに相当するトークンの無効化処理をしたい場合の処理です。これは、User EndpointsとBusiness Endpointsで若干変わります。
User Endpointsの場合
User Endpointsの場合はauth/token/revokeにAccess Tokenを渡すだけです。
Business Endpointsの場合
Business Endpointsではauth/token/revokeに直接相当するAPIがありません。このためチーム管理者が管理者コンソールよりチーム向けアプリケーションを無効化する必要があります。
8th December 2017 #api #dropbox #dropboxapi DropboxのAPIについて説明している日本語情報が少ないようなので、個人的にメンテナンスしているtoolboxというプロジェクトの経験をもとに説明していこうと思います。APIを網羅的に解説するよりは、勘所をつかむための解説にしようと思いますので詳細は英語版とはなりますが公式ドキュメントをご参照ください。またOAuthやJSON、curlコマンドなどWeb APIにて一般的な概念やツールなどについては説明を省略します。
なお、本記事は個人の見解であり、執筆時点での情報を元としています。記事の正確性などについて保証するものではない点ご容赦ください。最新情報については公式ドキュメントをご参照ください。
前置きが長くなりましたが今回は概要です。
Dropbox APIの種類
Dropboxより提供されているAPIには大きく分けて下記二種類があります。
- Dropbox API または User Endpoints … ユーザー毎のファイル管理など
- Dropbox Business API または Business Endpoints … Dropbox Businessチームの管理
なおドキュメントによって文脈によって単に「Dropbox API」とだけいったときに両方を含む場合もあれば、ユーザー毎のファイル管理だけを指す場合もあります。一部厳密性に欠ける部分もありますが、本記事では両方を指す場合にDropbox API、個別に種類を言い分けるためにはUser EndpointsとBusiness Endpointsという呼称を使うことにします。
API Explorer
ドキュメントを読み込むなどある程度準備してから取りかかるのもいいですが、まずは簡単に試してみるのが手っ取り早いでしょう。API Explorerというツールが公開されていますのでこちらを利用します。
左側にAPI一覧があり、APIを選択すると指定できるパラメータなどがフォームとして表示されます。わかりづらいですが、右上に「Switch to Business Endpoints」というリンクがありますのでBusiness Endpointsについても試すことができます。
ためしにフォルダ内のファイル一覧を表示してみましょう。APIはカテゴリ毎にパスが区切られていて、ファイル操作であれば https://api.dropboxapi.com/2/files/ 以下のエンドポイントが該当します。 この中の、list_folderというAPIがファイル一覧取得のためのAPIです。API Explorerではこのカテゴリ毎に整理されていますのでfiles以下からlist_folderを探してみてください。
まずは認証から。Get Tokenというボタンがあるのでこれを押してトークンを取得します。Dropboxへのログインや認可の確認などが求められますがそれらを確認のうえトークン文字列を取得してください。
早速実行してみましょう。Submit Callボタンを押します。パラメータpathに何も入れなければDropboxフォルダのルートからの一覧になります。逆に、ルートフォルダを一覧するために / は使えません。Show Codeボタンを押せばcurlでの実行例も表示されます。戻り値についてはlist_folder APIドキュメントに記載がありますが、正常ケース・異常ケースともに結果がJSON形式で返されます。
アプリケーションの登録
Dropbox APIを使って開発を進めるにはまずDropboxへアプリケーションの登録が必要となります。登録のためにはDropboxアカウントが必要となります。Dropbox開発者ページのMy appsから登録します。
APIの種別、アクセス範囲などを選択した上でアプリケーション名を登録します。アプリケーション名はDropboxサービス全体で一意になる必要があり重複した名称をつけることはできません。開発したいアプリケーションで複数のアクセス範囲を使いたい場合にはそれらアクセス範囲ごとにアプリケーションの登録が必要となるので、命名規則なども準備したうえで登録するとスムーズです。
アクセス範囲についての詳細は次の通りです。
User Endpoints
App Folder
アクセス範囲をアプリケーションのみが使用するフォルダに限定します。Dropboxフォルダ以下に「アプリ」またはユーザーの利用設定言語が英語などであれば「Apps」などのフォルダが作成され、このアプリフォルダ以下に/アプリ/アプリ名のようなフォルダが作成されます。App Folderを選択するとこのフォルダ以下しか操作することができません。
Full Dropbox
該当アカウントのすべてのファイルを操作できます。
Business Endpoints
Dropbox Business向けのAPIはチーム内のアカウント管理や監査ログを取得するなど目的に応じて範囲が分けられています。
チームに関する情報と利用統計情報などにアクセスできます。情報を取得するだけ管理など変更処理はできません。
Team auditing
Team informationの範囲に加え、チーム監査のために利用します。アクティビティ監査ログのような情報にアクセスすることができます。
Team member file access
Team informationならびにTeam auditingに加え、任意のチーム内アカウントへのファイル操作などアクションを実行することができます。たとえば、チーム内のアカウントすべての共有フォルダの共有先一覧を取得したいといった場合にはこのアクセス範囲を利用します。
Team member management
Team informationに加え、チーム管理者としての操作をするためのアクセス範囲です。チームメンバーを招待したり、アカウントの情報編集、削除などといった管理操作が可能です。たとえば、社内ワークフローと組み合わせて社内ワークフローで承認された人だけにDropbox Businessアカウントを招待するという用途にはこのアクセス範囲を利用します。
アプリケーションの設定
アプリケーションを登録すると設定画面が表示されます。OAuth2のGenerated access tokenという欄にGenerateというボタンがあります。これを押すと、既存のログイン済みアカウントで認可済みのトークンが生成されます。テストなどで利用すると良いでしょう。ちゃんとしたOAuth2シーケンスでトークンを取得する場合に必要となるApp key/secretについてもこの画面から参照することができます。
なおBusiness Endpoints向けのアプリケーションではこの操作を行うのは、そのチームのチーム管理者である必要があります。
Dropbox SDK
API Explorerで勘所がつかめ、アプリケーション設定が終わったらプログラミング開始です。REST APIなのでパラメータや戻り値を加工すれば何とでも呼び出しはできますが、やはりあらかじめ構造体/クラスなどが定義されたSDKを使った方が手軽です。
Choose your platformドキュメントを参照すると代表的なプログラミング言語用の公式SDKが一覧されています。執筆時点での対応言語は下記の通り。
GoやRuby向けなどこのなかにない場合にはコミュニティにてメンテナンスされているSDKも利用できます。
さらにコミュニティSDKもない場合、たとえばPowerShellで簡単な管理ツールを作りたいというようにこの中で対応言語がない場合にはHTTPのAPIドキュメントを参照しながら作成していくことになります。
SDKの選び方
APIはバージョン毎に互換性が保たれるよう提供されていますが、比較的頻繁に新しいAPIやパラメータ、戻り値が追加されるのでこれらに追従することを考えると公式SDKを採用した方がやや有利です。
Dropbox公式SDKはstoneというツールを使って自動生成されるようになっていますから、こういった変化への追従に強い点が特徴です。
一方で、お作法が統一されていて言語毎に特化した書き方ではないのでややなじみにくく感じる部分もあるかもしれません。
ファイルをアップロードするだけ、とかダウンロードするだけといった用途が一定または特化している場合にはコミュニティSDKのほうがなじみやすいかもしれません。
Dropbox APIの使い処
Dropbox上でできる主要操作はだいたいDropbox APIを利用すれば実現できます。また逆に、APIでなければ実現できないものもあります。少し実例を元に紹介していきましょう。
共有リンクのパスワード/有効期限を一括設定する
Dropbox ProfessionalやDropbox Business契約があるばあいには、共有リンクへパスワードや有効期限を設定することができます。ただ、共有リンク一つ一つに画面から設定するのは面倒なので一括設定したいと考えることもあります。こういったときにDropbox APIを利用すると実現できます。
たとえば拙作toolboxではこの操作を実装しました。
Business Endpointsのアクセス権「Team member file access」を使い、すべてのユーザーについて共有リンク一覧を取得します。
すべてのユーザーに対して処理を行うにはまずteams/members/listでアカウント一覧を取得します。各ユーザーについてsharing/list_shared_links APIでリンクを取得するのですがこのときに、Member file accessにあるとおり、HTTPヘッダにDropbox-API-Select-User: チームメンバーIDを追加すると、その該当アカウントとして処理が行われます。
共有リンクが取得できたら、同様にDropbox-API-Select-User: チームメンバーIDを使って、各ユーザーそれぞれの共有リンクについてsharing/modify_shared_link_settingsを使って有効期限を今日から7日後などに上書きします。
共有フォルダへの参加者一覧
監査などの目的でDropbox Businessチーム内の各利用者が参加している共有フォルダの参加者一覧を取得したい場合があるとします。 これも以前Pythonで実装したことがあります。
Business Endpointsのアクセス権「Team member file access」を使い、すべてのユーザーについて処理を行います。 共有フォルダの場合にはアクセス権限がメンバー単位だけでなくグループ単位の場合もあるのでグループ情報を取得するためにteams/groups/listなども使っています。
大量ファイルのコピー/移動/削除など
Web画面から操作する際にファイルが一定数を超えていると処理ができない旨が表示されます。Dropboxアプリケーション実行すれば大量ファイルでも処理はできるのですが、パソコン上に同期していない場合などでは処理ができないのと、パソコンにやや負荷もかかります。
このためそれぞれのファイルを逐次コピーないし、移動するようにUser EndpointsのAPIを使えば着実に処理を進めることができます。コピーであればfiles/copy_v2、移動であればfiles/move_v2といったAPIを使います。
なおAPIを使った場合でもAPIドキュメントにあるとおり10,000ファイル以上を同時に処理することはできません。
too_many_files The operation would involve more than 10,000 files and folders.
小分けにして処理する必要があります。
ログイン済みデバイス一覧や強制ログアウト
Business Endpointsのteam/devices/list_member_devices APIを使うとDropbox Businessチーム内のデスクトップ、モバイル、Webとそれぞれのセッション一覧を取得することができます。セッション情報には最終接続IPアドレスやUser Agentなども含まれるので、一定のルールを元に強制ログアウトを実施すると行った使い方もできます。たとえば、社内IP以外が検出されたら強制ログアウトなど。
強制ログアウトのためにはteam/devices/revoke_device_session APIを使います。
まとめ
Dropbox APIを使うと社内ワークフローと連携して自動処理を行ったり、運用ポリシーなどに合わせて管理する、あるいはDevOpsのように開発ワークフローと組み合わせて、Dropboxの特定フォルダにファイルがアップロードされたらビルド開始。といったことも実現可能です。
お作法はあるていどあるものの、一度覚えてしまえばやりたいことが簡潔に書けるようなAPIがそろっているかなと思います。
7th November 2017 #smallarticle #travel 海外旅行や海外出張に行く際、小物整理は意外とやっかいでした。今回はそういった海外旅行の際の小物整理で工夫していることをまとめます。旅行時の小物と行っても様々です。今回は次のように主に小さく薄っぺらいものをまとめて整理する方法について。
- パスポートや航空券など大事な書類
- 入国時の申請書類など
- 予備のクレジットカードやキャッシュカード
- 現地で受け取ったレシート (家計簿や経費精算などのために整理したい)
- 現地でもらったレストランなどのショップカード、観光地のパンフレット
- 現地で利用するSIMカードまたは、交換した日本のSIMカード
これまで数年はBRUNOのトラベルオーガナイザーを使っていました。パスポートや航空券、カード類が整理できるようになっていてとても便利です。それ以前は手帳に挟んだり、鞄のポケットにいれたり統一感無く管理していたので、入国管理や税関などで書類を提出する際もあたふたしていました。このトラベルオーガナイザーを使って整理したことで入出国時のストレスが少し解消されました。
革製でかっこよく、丈夫なので航空券が折れ曲がったりもせず気に入って使っていました。ただ、ここ数回の旅行では今までよりも小さな鞄を持って旅行していたのでこのわずかな厚みも気になるようになってしまいました。また、旅行先で受け取ったレシートなどもトラベルオーガナイザーに入れてしまうとかなり分厚くなってしまいます。 鞄には出張時であればノートパソコン(15インチのMacBook Pro)、iPad、携帯電話、それぞれの充電器(乗り継ぎ待ちの際利用)を入れていてこれだけでほぼ鞄がいっぱいに。この結果、トラベルオーガナイザーも出し入れがやや窮屈に。
また旅行券も以前はほとんどの場合、磁気ストライプのあるハガキぐらいのやや厚手な紙が使われていました。これが最近、バーコードを読み取るだけにかわり薄っぺらい感熱紙のような紙が使われる場合も増えてきました。あまり薄っぺらいと、トラベルオーガナイザーの収納ポケットの形によっては整理する際にやや手間取ります。
そこで直近の海外出張ではB6サイズのメッシュケースを使い始めました。よく銀行の通帳やキャッシュカードをひとまとめに整理するために使ったりするケースです。
なかなか丈夫で信頼性のあるケースで、何より価格も手ごろです。B6サイズのメッシュケースは210mm x 170mmとA5サイズがきっちり入るサイズです。このシリーズではマチの部分も考慮して一回り小さめの呼称をしているのだと思います。 あまり気にしていませんでしたが、最近乗ったJALやBritish Airwaysの航空券のサイズは20cmちょっと x 8cmちょっとでぴったり入りました。
このセキセイのメッシュケースはチャック部分が色違いの赤と青のものがあります。この2種類を目的別に使い分けることにしました。 一つ目はチャックが赤色のもので重要なものを入れます。これから利用する航空券やパスポート、SIMカードなど。 二つ目はチャックが青色のものであまり重要ではないものを入れます。レシートや地図など。
このように整理すれば入出国時にもバタバタしませんし、もともと薄手なのでかさばりません。重要ではない青色チャックのメッシュケースがもし手荷物に入らなければ、預け荷物に入れることもできます。
うまくいったので、2種類だけではなく、目的別にもう少し種類を増やしてみようかとも考えましたがあまり多すぎるとまたそれはそれでゴチャゴチャしてしまうのでせいぜい2種類ぐらいが良さそうです。
28th September 2017 #android #jelly #travel The Smallest 4G Smartphoneと、世界最小を謳う4GスマートフォンJelly。Kickstarterにて目標額を達成し、正式に発売されることになりました。今月上旬に手に入れることができたので少しレビューをしてみたいと思います。仕様などについてはKickstarterサイトや他のレビューなどが詳しいので、使用感を中心にレビューしたいと思います。
メモリー容量の違うJellyとJelly Proという2モデルがあり、メモリー容量が小さいJellyのほうは発売前に廃盤となってしまったのでKickstarter限定となってしまいました。今回購入したのはメモリー容量の小さいJellyのほうです。
なお残念ながら現状、技適を取得していないため日本では電波を発することができません。海外旅行時のバックアップ用として購入しましたが、ちょうど今月海外へ行く機会があったので実際に使ってきました。SIMはMTXCのものを準備しています。1GB、15日間で約20ユーロです。
今回はヘルシンキ、ダブリン、ロンドンで使ってきました。世界最小を謳うだけあり、確かに小さい。まだ現役で使っているiPhone 5sよりもずっと小さい。画面も2.45インチでキーボード入力などもかなり難しく、バリバリ使う。というよりは、補助的な利用方法がメインになるかと思います。
Google Mapで地図を確認するにも小さすぎ、実用上は大雑把に把握する程度に考えておいた方が良さそうです。一方で、Turn-by-turnナビゲーション機能を使った場合はそれなりに視認性もよいので、このスマートフォンで一番しっくり来るように思いました。画面をずっとにらめっこするタイプではなく、信号待ちのときなどに方向を確認するぐらいの使い方が合っているのでしょう。
街歩きで使ってみたところ、デジタルコンパスがなかなかうまく正しい方向を向いてくれません。しばらく歩いていると方向があってくるので、街の風景を楽しみつつときどき方向を確認するぐらいでいいのだと思います。
バッテリーがどの程度持つかは気になるところでしたが、全くゼロになることはありませんでした。ただGoogle Mapなどそれなりに使っていると丸一日は持たないかなというぐらいの印象で、やはりバリバリいろいろ調べながら街歩きをするためのスマートフォンではありません。周りの風景を楽しみながら適当に散策し、迷子になったり時間の余裕がなくなってきたときの最終手段としてポケットに忍ばせておくぐらいのつもりで使っていると便利でしょう。
予備バッテリーを持ち歩くという手段もありますが、バッテリーを持ち歩くぐらいだったら、iPhone 5sのほうがバッテリーの持ち、サイズ感など考えた場合により使いやすいと思います。電波の入り方はヘルシンキ、ダブリン、ロンドンのいずれでも特に不満はなくGoogle Mapも普通に利用できました。
総評:
知らない街をあるくときの安心材料としてポケットに入れておくぐらいの使い方が良さそうです。レビューを見ながらレストランを探したり、写真を撮ってSNSにアップロードするような使い方は向いていません。ぶらり入ったレストランがたまたま美味しかったり、適当に歩いた先にあった公園がきれいだったりするのを楽しみながら旅するためのスマートフォンです。
30th August 2017 #ccc #java #jjug 
ブログを書くまでがJJUG CCC、ということではありますが、かなり、、時間が経ってしまいました。6月頃に書き始めたものを再編集しているのと記憶もややあやふやな部分があり不正確な点もあるかとおもいますがご容赦ください。JJUG CCC 2017 Springへ参加した話を思い出しながらまとめています。
今回は年次総会の後に行われたJJUG CCC 20th fireside chatというセッションにて登壇させていただきました。発表者は「20回生き残っている幹事たち」ということでしたが、僕が実際にJJUG幹事として参加させてもらっているのは手元の記録が確かならば2009年6月からで20回すべてには幹事として参加していませんが、最初の頃はSun Microsystems社でJavaエバンジェリストとして関わっていたというオマケで加えてもらっています。
お話しした内容は当日のアドリブで、正確には覚えていませんが大まかに当日お話した内容に注釈を加えつつ振り返ってみます。
RIA
2007年頃といえばAdobeのAir、MicrosoftのSilverlightといったRIA (Rich Internet Application)が流行っていたように思います。RIAという言葉はほぼ死語ですが、現在のスマートフォン・タブレット向けのアプリ、あるいはMac App StoreやWindows StoreのようなデスクトップアプリとしてRIAという言葉は消え去ってもコンセプトとしては完全に当たり前のものとなりました。
初代iPhoneもこの年に発表されていますが、RIAの流れに続く原動力を作ったのは個人的には2005年にGoogle Mapsがリリースされたことだと思っています。個人的にも衝撃的でしたし、多くのインターネットユーザーや企業IT部門の考え方まで大きく変えていった原動力になったのではないかと思っています。当時、Web上で地図を見ると言えば住所で検索したり、上下左右ボタン、縮尺変更を押して切り取られた地図を次々に見ていく。というスタイルだったと思いますがマウスによるスクロールや縮尺変更は圧倒的にわかりやすく仕上げられていました。AjaxというWebテクノロジーもGoogle Mapsの発表を境に大きく花開いたと記憶しています。
さて、Java界でのRIAといえば、JavaFX。もともと、ICAN SuiteというSOA基盤ソフトウエアで知られていたSeeBeyondという会社を2005年にSunが買収したところが始まりです。SeeBeyondに在籍していたChris Oliverが個人プロジェクトとして作っていたF3というスクリプト言語が出発点となっています。2007年5月のJavaOneではJavaFXという名前で目玉としてキーノートにて発表されました。
当時の記事を少し読み返してみました。
2007発表されたJavaFXではJavaFX Scriptというスクリプト言語が同時に発表されています(これはまさに前述のF3そのものです)。GUI記述について、無理なく自然な記述ができるスクリプト言語です。JavaをiOS/macOSにおけるObjective Cとするならば、JavaFX ScriptはSwiftのような存在です。
F3という名前は”Form Follows Function” (形態は機能に従う)を元としているそうです。Chrisとは話をしたことはありませんでしたが、JavaOneセッションやブログなどで発信されていた彼のF3へのこだわりと、JavaFXをJavaのRIA基盤としてエコシステムを築き上げたいSunとの思惑は当時から少しずつずれているように感じていたように記憶しています。
その後、JavaFX 2.0が2011年に発表されるとJavaFX Scriptは廃止となり、Javaからネイティブに呼び出しができるライブラリの一つとなりました。2011年、すでに多言語実行プラットホームとなっているJavaにとって、ライブラリとして存在を変えることはまさに”Form Follows Function”であったのだと感慨深く思い出します。
Webサービス
10年程度前で記憶のあるトピックとしては2006年、Project Tangoという名前で.NET(Windows Communication Foundation)とJavaをWebサービスで相互運用するという発表があったことです。Project TangoはWeb Services Interoperability Technology (WSIT)という名前の成果物でWS-Security、WS-PolicyなどWS-I基礎的な仕様についてまとめ相互運用できるようパッケージ化されたものです。
今でこそ、APIを使ったサービス間連携というのはもはや何の疑いもなく当たり前のものとなっていますが、.NETとJavaで相互運用するということだけでニュースバリューになるぐらい相互運用するというのはまだ早熟な時期であったと思っています。
その後、RESTful APIというキーワードに注目が集まりより簡単にAPIが提供でき、利用できるになりプログラミング言語やOS環境に依存しないという土壌はどんどん整っていきました。
電話をかけるAPI、テキストを翻訳するAPI、株価や天気予報のAPIなど様々なAPIを組み合わせて新しいサービスを作るというのはシステム開発のなかでも珍しいことではなくなりました。Mashup Awardsという取り組みも2006年に始まっていていまもどんどん規模を拡大しているようです。
前述のようなRIAが目指した使いやすいインターネット向けUIはAPIを通じたサービス提供ならびにサービス利用が増えるに従ってその地盤を確固たるものになっていったものだと思っています。サーバサイドで起こっていた相互運用性やSOAなどのようなエコシステム、スマートフォンやタブレット、デスクトップ環境向けの「アプリ」というエコシステムは決してどちらか片方だけでは成り立ち得なかったのだろうと思っています。