今年の初め，3scaleは，API利用者をターゲットにしたAPIToolをローンチした。InfoQでは，同社でAPIToolsのプロダクトおよびマーケットリーダを務めるVanessa Ramos氏に，APIToolsを開発した動機やベースとなったアーキテクチャ，ユースケース，ロードマップ，コミュニティ施策などについて話を聞いた。
InfoQ: APItoolsを開発した動機と，想定するユーザ層について教えてください。
今日のWebやモバイルアプリケーションは，さまざまなAPIを利用して機能しています。ですが，そのような外部システムにコントロールを委ねていることは，大きな弱点にもなります。APItoolsはこのような課題を抱えたアプリケーション開発を支援するもので，アプリケーションのすべてのAPIトラフィックを簡単に素早く追跡し，監視することができます。APItoolsは開発時と運用時，どちらでもAPI利用者を支援できるように設計されています。
APItoolsはLuna + Nginx (OpenResty) を使って開発されました。APIトラフィックの追跡と変換，解析を可能にするバックエンドプロキシなのです。
InfoQ: 3scaleのAPI管理プラットフォームとは別の製品として提供するのはなぜでしょう？同じ基盤技術を共有しているのですよね？
現時点では，当社のプラットフォームでAPIの開発と管理を行っているユーザのニーズや要求と，APIを使用するユーザのそれらとが大きく違っているからです。ですから，これまでカバーできていなかったセグメントを明確なターゲットにした新製品として，APItoolsを開発しました。
3scaleとAPItoolsはRedisやNginxなど，いくつかの基盤技術を共有していますが，固有の部分についてはまったく新たに，ゼロから作り上げています。確立済みの強固なコアを再利用して，別の具体的なニーズに合うように拡張するチャンスでもあります。
InfoQ: APIライフサイクルのどのフェーズを対象として設計されていて，どのような利用方法を想定しているのでしょう？運用時の使用は可能なのですか？
まず最初に明確にしておきたいのが，この製品では，APIライフサイクルをAPを利用する側の視点から捕えているということです。特に調査，統合，開発，そして運用中といったフェーズです。APItoolsは開発中のテストやデバッグの便宜上，これらのフェーズをある程度カバーしています。ですが，もっとも重視しているのは稼働フェーズですね。
InfoQ: 運用時のトラブルシュートで，どうやってエンドユーザ個々のトラフィックを識別したり，分類したりするのですか？
APItoolsにはそういったユーザという概念は組み込まれていません。トレースを監視して，いくつかの処理を行った上で(オプション)再送信する，という意味で，インテリジェントなプロキシとして機能するのですが，"user_idに特別な注意を払う"ことはしないのです。調査目的で特定のユーザのトラフィックを分離したいのであれば，ユーザの要求に識別情報を含めておく必要があります。ヘッダフィールドにトークンを含めるか，ユーザごとにURLを区別するような方法になるでしょう。APItoolsでも既存のフィールドを使ってフィルタすることは簡単ですが，ミドルウェアを通じて指示しない限り，新たにフィールドを追加するようなことはありません。
InfoQ: ミドルウェアでのAPIセキュリティやトラフィック管理，モバイル対応などについて，初期状態のポリシはどのようになっていますか？コミュニティによる貢献も考えられているのでしょうか？
はい。最初のステップとしては，オンプレミス版のローンチに向かって進んでいます。次のマイルストンはミドルウェアコンポーネントの共有レイヤの開発と，そのミドルウェアを中心にコミュニティを構築することです。すばらしいミドルウェアはすでにあるのですが，今述べたような優先順位で考えていますので，直近のステップとしては，ホスト環境と同じようにオンプレミスでもAPItoolsを使えるようにしたいと思っています。
InfoQ: ミドルウェアポリシを定義するための言語として，Luaを選択したのはなぜですか？
Luaは当社の主力製品であるNginxプロキシでも活用しています。クリーンですばらしい言語です。しかもインラインのサーバ操作が驚くほど高速です。他の選択肢としてありそうなのはJavaScriptですが，まったく問題になりません。それにLuaには，どのようなミドルウェアでも安全に利用できる，優れたサンドボックス/アイソレーション性もあります。
InfoQ; APItoolsのAPIを公開する予定はありますか？
はい，その予定です。ですが今はまだ，公開するデータを決定している段階です。開発者がより強い興味を持って利用してくれるデータを提供したいと思っています。
InfoQ: Active Docsはどのように使用されるのでしょう？
おもなユースケースは２つです。ひとつは"visual curl"で，構造体にあらかじめ情報を設定しておくことで，呼び出しや結果確認の繰り返しの高速化を実現するものです。矢印を使って200文字のcurlコマンドを編集している人があまりにも多いですからね。そしてふたつめは，APIが使用されている表面積の大さや，実際の使用状況について知ることです。１対１で通信する内部アプリ用には，コールを再現するコンソールがあります。内部API用の(ベーシックな)GUIジェネレータと思って頂ければよいでしょう。
InfoQ: APIを利用する上でもっとも大変なのは，APIの変更に継続的に対応するためのメンテナンス作業だと思います。APItoolsでは，コードのメンテナンス作業は簡単になるのでしょうか？
もちろんです。まず最初に，例えばHTTP要求がエラーをスローした場合や，予想以上に時間が掛かっている場合を通知するように，Eメールによるアラートを設定することができます。例えば，HTTPが200でない場合にミドルウェアがEメールアラートを受信するには，次のようにします。
return function(request, next_middleware)"レガシツール"あるいは"非推奨ツール"として使うことも可能です。APIの変更の複雑さによりますが，APItoolそれ自体で，以前のバージョンへのフォールバックを実装することも可能です。
local five_mins = 60 * 5
local res = next_middleware()
local last_mail = bucket.middleware.get('last_mail')
if res.status ˜= 200 and (not last_mail or last_mail < time.now() - five_mins) then
send.mail('youremailaddress@domain.com', "Something's going on...", "request is not a 200, see"..request.uri_full)
bucket.middleware.set('last_mail',time.now())
end
return res
end
例えば，APIの新バージョンであるフィールド(user_id)が変更されたような場合には，ミドルウェアを使って”移行期実装”を提供することができます。
return function (request, next_middleware)
local res = next_middleware()
‐‐ Transform the user_id back to a string if the user requested version 1 of the API. But add a deprecation warning too
if request.headers['Version'] == "1" then
local body_data = json.decode(res.body)
body_data.user_id = tostring(body_data.user_id)
body_data.deprecation_warning = "WARNING: Version 1 of the API will stop being supported on the 2015-‐01-‐01. Please update to Version 2"
res.body = json.encode(body_data)
end
return res
end
この仕組みのメリットは，バージョン１のAPIがEOL(end-of-line)に達したときでも，単にミドルウェアを取り除けばよいということです。サーバ自体に手を加える必要はありません。Eメールを送信して廃止を警告するような，もっと手の込んだ処理を行うことも可能です。最初からAPIのバージョン2.0を使用することができますから，APIコード自体のメンテナンスも簡単になるでしょう。APIとAPItoolsという２つの場所にコードを配置することになるので，管理上のコストはいくらか必要になるかも知れません。バージョン変更の複雑さと，バージョン１を継続的に使用するクライアントの予想数によるトレードオフが必要でしょうね。中期的にはこのような作業を，APIの最新の変更やパッチ，ドキュメント更新などに関するコメントとして利用することもできるでしょう。
InfoQ: 今後予定されている機能で，コミュニティの関心を呼びそうなものを教えてください。
間もなくローンチ予定のオンプレミス版以外としては，ミドルウェアコンポーネントの共有レイヤの開発を計画しています。他の開発者が独自のニーズで開発したコンポーネントの再利用や適用を可能にすることで，APIを簡単に利用できるようにしたいと思っています。