サンノゼの“I love API”カンファレンスの後，InfoQはApigeeのEd Anuff, Marsh Gardiner両氏と話をする機会に恵まれた。ApigeeとAPIビジネスへの一般の認知度を大きく高めた4月のIPO後，同社は，アプリケーションの構築方法やAPIの使われ方を理解することで，APIテクノロジを新たな領域へと進めようとしている。
InfoQ: Apigeeはこの数年間で急成長しましたが，API開発者やチームにどのようなテクノロジを提供しているのですか？
Ed Anuff: Apigeeが基本的に注目しているのはAPI管理です。開発者が組織の内外で，APIをもっと簡単に使えるようにしたいのです。当社がAPI StudioでカバーしているAPI設計などの他にも，非常に多くの面があります。既存の業務システム(Systems of Record)に対応して，ディジタルエクスペリエンスのサポートを約束するシステムへと転化する，私たちはそのような開発者たちを支援します。
Marsh Gardiner: さまざまなデータをさまざまなアプリケーションに接続する方法を見出す上で，それが大きな位置を占めています。バックエンドシステムやアプリケーションの開発手法(モバイルアプリ，IoTなど)について，いろいろと考えています。
InfoQ: 大企業ユーザや中小企業ユーザのAPI採用や成熟度は，どのようなレベルにあると見ていますか？
Ed: そうですね，APIに関して以前と違うのは，誰でもAPIを使用するようになったことです。もっともAPIやRESTなどについて，すべて詳細に知っているかどうかは別の話ですが。今問題なのは，APIをどの程度利用しているかという点ですが，私がこの世界に入って４年間で，大きな変化がありました。
かつてAPI採用の検討を始めた企業が，現在ではそれを実践しているのですが，それは彼らが専門家になったという意味ではありません。データベースの場合と同じことです。ですから次の問題は，APIの設計方法やAPIライフサイクルの管理手法について，彼らが理解したいと望むかどうか，という点です。
Marsh: 当社の大手ユーザは，SoR(System of Record)に関してサンクコストを抱えていることが少なくありません。彼らはSoR内にあるデータを，アプリやSoE(System of Engagement)に公開する方法を知りたがっています。大企業は組織の硬直化に悩まされていることが少なくありませんから，APIが自分たちのビジネスに与える影響について，違った考え方を持つのは難しいのです。
InfoQ: 今回のカンファレンスでApigeeは，APIのデザインファーストアプローチを強く支持する立場を取っていましたが，その意味するところを説明してください。APIコードファーストから今，大きなシフトが起きているのでしょうか？
Marsh: 私たち自身がAPI開発において，ある種の問題に突き当たったのです。５年前の私たちは，Google Docで記述したAPI仕様を開発チームに提供して，運がよければ多少なりともそれに合ったAPIを受け取ることができる，といった状況でした。
この方法にはいくつか問題があります。ドキュメントでは考え得る詳細すべてを網羅できないがために，実装作業時の解釈に影響を受けてしまうのです。最も重要なのは，スタート時点では有力な推測に過ぎないものを実装するためには，設計でその間を補完しなくてはならない，という点です。
それをデザインファーストと呼ぶのは，多少の誤りを含んだ名称かも知れません。デザインフェーズが終了することを前提としているように思えるからです。コントラクトを基本とするこの開発プロセスのメリットは，設計と実装が並行して繰り返されるという点にあります。長い間待ち望んでいたバージョンが完成して，他の人々に利用を呼びかけられるようになるまで，API設計が終了することはないのです。
従来の方法で最後に残る課題は，サービスがサービスとして立ち上がるまでクライアントの開発ができないことです — ですが，Swaggerドキュメントのようなフォーマルな仕様があれば，モックサービスを用意することで，クライアント側とサーバ側を並行して開発することは可能です。
InfoQ: API Studioのベータ版が５月に発表されました。提供される機能を，オープンソースのSwagger Editorと比較して説明して頂けますか？
Marsh: API Studioでは，Swagger Editorなど私たちがこれまでコミュニティにコントリビュートしてきた，多数のオープンソースプロジェクトの成果に加えて，サーバ側コンポーネントでは行うことのできなかった機能も提供されています。Swagger Editorはブラウザベースのクライアントなので，モックを使用するためには，適切なサーバ側コンポーネントを用意する必要がありました。
Ed: Swagger Editorはオープンソースですが，主体となって開発したのはApigeeです。Swagger EditorはNode.jsとバックエンドを使用しますが，すべてのユーザが自分たちでインストールしたい訳ではないので，最初はクラウドにホストされているバージョンをセットアップすることになります。その後で，モックサービスなど便利な機能を追加することができるのです。
Marsh: API仕様で他の人たちとコラボレーションできることも，重要な特徴のひとつです。
InfoQ: Apigee API Consoleでは，APIコントラクトの提供にWADLが使用されています。SwaggerはApigee API Studioのベースですが，API言語をサポートする方向に進む計画は現在，どのようになっているのでしょう？
Marsh: Apigee API ConsoleはSwaggerよりも前に開発されました。 その当時はWADLが優れたフォーマットだったのですが，現在はSwaggerに関係した標準を確立しようと努力しています。
Ed: RAMLやAPI Blueprintのような優れた開発をしている人たちもいますが，私たちはひとつに集中して成果を上げたいと思っています。フォーマットが違っても，インポート/エクスポートという手段もありますから。
InfoQ: ApigeeはこれまでSwagger，特にSawgger Editorに大きな貢献をしてきました。ところで先日，Swaggerのスポンサーシップが別のAPIソリューションベンダのSmartBearに代わりましたが，これによってプロジェクトへの貢献度に変化はあるのでしょうか？
Ed: Swaggerに関しては，オープンな基盤を構築した数多くの活動があります。当社はその大きなサポータです。この成果として先日，Linux Foundationの下にOpen API Initiativeが設立されました。
Marsh: 私たちは今後も，Swagger仕様に基づいて，コミュニティにオープンソースコードを提供していきます。Swagger仕様こそが未来のフォーマットだと，固く信じているのです。
InfoQ: Ed，あなたはApache Usergirdの基本技術のオリジナルを開発していますが，このプロジェクトはここ何年間でどのように進歩して，API開発者をどのように支援していますか？
Ed: Usergridは主にモバイル開発者のためのバックエンド・アズ・ア・サービスですが，他分野の開発者でも利用可能です。非常にスケーラブルなアイデンティティとデータストレージの他，プッシュ通知のようなサービスも提供します。Apigeeでも使用していますが，これもオープンソースです。私たちはUsergridをApache Foundationに寄付しました。すでにインキュベータを卒業して，トップレベルプロジェクトになっています。
たくさんの開発者が使用し，コントリビュートすることで，プロジェクトは大きく進歩しています。 Cassandraをベースとしていますが，開発チームがElasticsearchも追加しました。
スケーラビリティもさらに向上して，現在では1秒あたり10,000件以上のリクエストを処理可能です。すべてREST APIに基づいているので，API開発者にもメリットがあります。とても有望なプロジェクトで，カンファレンスでのUsegridのセッションも満席でした。
InfoQ: Marsh，あなたはMartin Nally氏と，カンファレンスの“Pragmatic REST”という講演で，サービス指向とデータ指向のおもな違いについて話していましたが，一般的に実践されているRESTや，純粋なREST原則とはどのように違うのでしょう？
Marsh: 大きな違いは，純粋なRESTには多くの制約があることです。私たちはもっと実用的なアプローチを取っているのです。例えば，私たちは，ハイパーメディアがアプリケーション状態のエンジンでなくてはならないとは考えていません。この時点でHATEOASの必要があるとは見ていませんが，ハイパーメディアを含むRESTには多くのメリットがあるという考えなのです。
その背景には２つのペルソナがあります。機能の公開を関数レベルで考えている開発者にとっては，サービス指向は自然な方法です。これに対してデータ指向では，データの表現方法やエンティティ間の関係で考えます。このことを確認する最善の方法は，Usergridの私たちの製品でこれがどのように実現されているかを見ることでしょう。
Ed: ハイパーメディアは実際には，いまだ実現されていない理想に過ぎないのですが，ガバナンスなしでAPIを実現する唯一の方法でもあります。ガバナンスを行うというのは，SOAを行うことです。人々がハイパーメディアを求めるのは，知りたいことがすべてAPIにあるからだと理解しています。ハイパーメディアがなければ，知らなければならないこと(セキュリティやガバナンスのような)はドキュメントにあります。ハイパーメディアが好まれる理由はそこにありますが，完全な実現は不可能かも知れません。
Marsh: 私の意見では，ハイパーメディア駆動(hypermedia-driven)APIは“ジャスト・イン・タイム・コントラクト”の一種だと思います。コントラクト駆動(contract-driven)とは世界観が根本的に違います。どちらが優れているということではなく，状況がまったく違うのです。
Ed: Zetta.jsは当社のオープンソースIoT APIソフトウェアですが，デバイスをコントロールするための，極めて堅牢なハイパーメディアAPIを備えています。ハイパーメディアで何ができるかという好例だと思います。
InfoQ: Pragmatic RESTでは，バージョニングはどのように扱われるのでしょう？
Marsh: Martinは今回の講演で，バージョンはサブドメインに置く方がよい，と指摘していました。APIコントラクトには反していても，それ自体は処理手順を棄損していないという，この２つの区別に注目してほしいと思います。将来的に変更の余地があるという理由でリソースに置く場合も多いのですが ... それが最大の理由なのだとすれば，特にそうする価値はないでしょう。
InfoQ: 今日のAPI開発者の大部分が，機密性についてはHTTPSに，認証についてはHTTPベーシック認証あるいはOAuthに頼っていますが，今後はJWT/JWE/JWS, HMACのような新しいセキュリティスキーマとディジタル署名が普及するのでしょうか，あるいは単にニッチなソリューションで終わるのでしょうか？
Marsh: JWTはOAuthの改良であって，OAuthに代わるものとは思いません。トークンを扱う上では，独立的に検証可能である，有用な情報を含めることができる，などの点で優れた方法です。
Ed: JWTはスケーラビリティの上で重要ですので，強く支持しています。現在はJWTトークンにシフトしているところです。
Marsh: HMAC署名は昨年以降，特にセキュリティを非常に真剣に捉えている企業ユーザから，頻繁に話題に上るようになりました。彼らは完全性を保証するため，ペイロードの暗号化を望んでいるのですが，反対意見もあって，採用に対する障壁になっています。ある程度まではSDKを使って解決できるかも知れませんが，サポートとメンテナンスの対象とする予定の言語がN個あるとすれば，N+1個の問題を抱えることになるのです。HMAC署名が話題になった場合，私は必ず，それが本当に必要なのか，開発者に苦痛を強いるだけの価値があるのかを理解するように努めています。
InfoQ: 新しいApigee Senseプロダクトは，セキュリティ面でAPIチームをどのように支援できるのでしょう？
Ed: Webサイトでは，誰かがスクリーンスクレーパやボットを使ってコンテントを盗もうとしたり，あるいはWebサイトを攻撃したりする可能性があります。現在ではこれらすべてがAPI経由で行われるので，Senseはこの問題を，APについて解決しようというものです。Senseでは予測分析を使用しますが，これは私たちが以前から行っていた方法です。当社はInsghtsOneというビッグデータ企業を買収しました。この方法は，APIをコールしているのが正規のユーザなのか，さらには適切な権限を持っているかを，機械学習を利用して判別する，という考えに基づくものです。
Marsh: Senseはネットワークファイアウォールを遥かに越えています。
InfoQ: 今日のAPIテストに関して，最も求められているものは何でしょう？それに対してAPI Healthは，どのように役立つのでしょうか？
Marsh: 現代的なAPIであれば，シンセティック(synthetic)およびオーガニック(organic)いずれのトラフィックも監視する必要があります。ですからカンファレンスでは，オーガニックトラフィックとそのエンドツーエンドのパフォーマンスを可視化するAPI Pinpointについて話をしました。しかしシンセティックテストも，APIライフサイクルにとっては同様に重要です。最新のビルド候補がAPIコントラクトに反していないことを知るために，さらには定期的にサービスのパフォーマンスを検証するためにも使用できます。
InfoQ: 技術的な観点から見たAPIの将来は，どのようなものなのでしょう？リアルタイムやWebフック，ラムダといったものは，明日のAPIを根本的に変化させるのでしょうか？
Ed: Webフックが最も大きいでしょう。APIに関しては誰も言及していませんが，最も期待の持てる機能です。WebフックはGitHubやSlackなど，多くの場所で目にするものですが，それが今，SaaSを拡張可能にする方法として用いられています。マイクロサービスよりも重要だと思います。
それを説明するために，私は“ツーウェイ(two-way)API”ということばを使っています。マイクロサービスはワンウェイAPIですが，Webフックではサービスが他のアプリケーションを呼び出すことが可能になります。Slackのおかげで，多くの人たちがWebフックを経験しているのです。
Marsh: Webフックの興味深い特徴のひとつは，承認が逆方向であることだと思います。従来のAPIではOAuthが一般的な標準ですが，Webフックではこちらからシステムを呼び出します。そして要求元を検証するために，APIキーのような共有秘密情報を使うのが一般的です。そのトークンを評価するかどうかは，Webフックの受信側次第です。Ed: 誰もがマイクロサービスを話題にしますが，その意味について合意が取れているのかどうかは分かりません。ですがRESTということばは，皆が使っています。先にも行ったとおり，”マイクロサービスが好きならば，SOAを好きになる”はずです！