11月の初め，Linux Foundationが発表したOAI(Open API Initiative)にあげられた華やかな創設メンバ一覧を見たAPI開発者たちは，標準に関するコンセンサスを推進するというOAIの役割に疑問を持たざるを得なかった。
Swaggerプロジェクトの創設者であるTony Tam氏は，11月末にテキサス州オースチンで開催されたAPI Strategy and Practice Conferenceで，このような疑問の中のいくつかを取り上げた。読者も関心を持つであろうこれらの疑問について，より詳しい回答を得るべく，InfoQはカンファレンスに氏を訪ねた。
InfoQ: SmartBearにおけるあなたの新たな役割と，参加を決めた理由について教えて頂けますか？
Tony Tam: 私がSmartBearに加わったのは，Swaggerの開発をフルタイムで行なうことのできる初めてのチャンスだったからです。私はSwaggerに関して，プロフェッショナルサポートやオープンソース，SwaggerHub，Open API Initiativeへの参加などの面で責任があります。
InfoQ: OAI(Open API Initiative)が先日，Linux Foundationの下で発表されましたが，これはどのようなものでしょうか？
Tony: OAIの目標はSwagger活動の根本である仕様そのものについて，中立かつオープンなオーナシップを提供することにあります。OAIは，Swaggerを運用する多くの大企業からの，多額のインフラ投資をもとに創設されました。それらの投資を通じて各社は，仕様の将来と方向性への発言権を確保しておきたいと思っているのです。
SmartBearはLinux Foundationへの協力を通じて，API仕様の公開性と一貫性の価値を理解する先見の明を備えた，ごく少数の企業のリストに名を連ねています。寛大にも同社は，Swagget仕様の所有権をOAIワークグループに譲渡してくれたのです。
InfoQ: 2015年始めにSmartBearがスポンサーシップを引き継いだ後のSwaggerのガバナンスについては，非常に高い関心が持たれていますが，このようなガバナンス構成につながった分析や意思決定がどのようなものだったのか，説明して頂けますか？
Tony: ツールやインフラストラクチャを手掛ける企業にとって重要なのは，より優れたツールやサービスを構築する上で共通の言葉を使うことです。Swaggerはまさに，その共通言語として使うことができます。
仕様をオープンガバナンスに移行し，MicrosoftやIBM, Googleといった企業の支援を得ることで，ツールやインフラストラクチャのサービス化が促進され，Swaggerで記述された開発者向けの共通インターフェースとツールが整備されるようになります。
Linux Foundationを選択する前，私たちは，ポピュラーかつモダンな多くの組織について検討をしましたが，OAIの性格(仕様対ソフトウェア)を考えると，Open Container Initiativeなどに関して同じような活動経験を持つLinux Foundationは，最も理に適った選択肢であったと思います。
InfoQ: 企業メンバと草の根コミュニティは，それぞれどのような役割になるのでしょう？大企業が直接関与することによって，今後のOAI仕様(Open API Format?)がCORBA化するリスクはないのでしょうか？
Tony: 大筋はすでに決定しているので，CORBAのようになるリスクがあるとは思っていません。Swaggerのようなものをスクラッチから開発するのであれば，そのような可能性もあるかも知れませんが，ワークグループの創設メンバはみなSwaggerが成功した理由，すなわちコミュニティについて知っています。
善良なコミュニティを維持するためには，Swaggerが作り上げてきた本質的な価値を守らなくてはなりません。私たちは意図的に，ベンダ以外の，知識を持ったAPIユーザもワーキンググループに招待しています。APIによって即時解決すべきビジネスニーズを持った彼らが参加することで，フォーマットの実用性を維持できるからです。
InfoQ: 競争と成熟の結果としてAPI BlueprintとRAML, そしてSwaggerには，相違点よりも共通部分の方が多くなったように思えるのですが，これらをひとつのAPI記述言語にまとめることは，技術的に可能だと思いますか？
Tony: フォーマットに技術的な相違点があることは事実ですが，いくつかの面での共通化は可能だと思います。思想的には大きな違いがあり，その点については今後も変わらないでしょう。
InfoQ: 2015年に立ち上げられたOpen Container Initiativeでは，競合企業であるDockerとCoreOSが共通のコンテナフォーマットの下に再統合されていますが，API BlueprintとRAMLのスポンサーであるApiaryとMuleSoftに，OAIへの参加を奨める意思はありますか？
Tony: もちろん，参加希望者すべてに対してオープンですから。
InfoQ: APIコントラクトの記述ではなく，別の方向からAPI定義を目指しているAPI.jsonやAPI Commonsといったイニシアティブがありますが，これらは共通API言語の一部として，OAIの傘下に収束すべきでしょうか？
Tony: API記述仕様以外に，さまざまなフォーマットが存在することは不自然ではありません。実際にSwahggerHubでは，apis.jsonフォーマットを使用しています。それも同じフォーマットの一部であるべきなのかは分かりません。OAI仕様ですべてのユースケースをカバーして，最終的にWADLのYAMLバージョンのようにするという考えはないのです。
InfoQ: コアコンポーネントであるSwagger仕様がOAIに寄贈された今，Swagger Frameworkとしての目標は何ですか？
Tony: 仕様がOAIに移管されたので，開発者がそれらのサービスに接続できるように，Swaggerツールはその実装に着手する予定です。Swagger OSSツールは今後も完全にオープンで，SmartBearはコミュニティ関連のサポートのみを展開します。
InfoQ: 今後，Swagger仕様に代わるものとしてOAI仕様を理解するべきなのでしょうか，あるいはOAI仕様はSwagger仕様を出発点として，これから定義されていくのでしょうか？
Tony: 既存のSwagger仕様がそのまま移管されて，ワークグループの管轄下に置かれることになります。OAIは技術チームの準備ができ次第，OAI仕様 – Swagger仕様をベースとしたものになると思います – をリリースする予定です。ですから，あなたの質問に対しては，OAI仕様は既存のSwagger仕様と差別化するために大きな変更を導入する予定である，とお答えします。Swagger仕様とは違うものになるでしょう。
ツールとオープンソースソフトウェアのSwaggerエコシステムは今後もSwaqgerという名称で，これまでどおりオープンで中立であり続けます。準備ができれば，OAI仕様もサポートする予定です。Swagger.ioは，誰が作るものであれ，引き続きSwaggerエコシステムに最良のツールを提供していきます。
InfoQ: CodegenフロントなどSwagger Frameworkでリリースされた最新の機能強化には，何がありますか？すべてのコンポーネントが仕様のバージョン2.0をサポートするようになったのでしょうか？
Tony: 最新リリースはSwagger Inflectorという，Swaggerを使用したJava用APIフレームワークです。Swaggerの定義からアプリケーション全体のコード自体を生成します。11月初めにリリースされたのですが，高度な方法でAPI定義から反復的なコードの多くないAPIを構築することのできる，数少ないフレームワークのひとつだと思っています。
Swagger Codegenのメジャーアップデートは，11月の初めにリリースされました。コミュニティ主導のコントリビューションを約170件プルすると同時に，TypeScriptサポートなども変更されています。JavaScriptクライアントも11月末にアップデートされて，Promiseパターンなどの高度なインタセプタパターンが追加されました。コアツーリングに関しては，今後数週間の内にもっと多くのリリースがある予定です。
現在ではSwagger公式プロジェクトのダウンロードの4分の3が，バージョン2.0仕様に関するものになっています。ツーリングも大部分において，バージョン2.0構文がサポートされています。コミュニティが開発しているプロジェクトにはまだ旧バージョンを使っているものもあるので，相互運用性に関するツーリング開発支援は今後も続けます。ソフトウェアは１バージョン前と互換性を持たなければならない，というのは私たちの理念なのです。Codegenでも２年前の1.2フォーマットをサポートしています。
InfoQ: 先日サンタクララで開催されたAPI WorldカンファレンスでSwaggerHubの発表がありましたが，それがどのようなもので，Swagger Frameworkとはどのような関係にあるのか，詳しく説明して頂けますか？
Tony: SwaggerHubは，オープンソースSwagger製品をSaaSサービス内で使用することによってAPIを設計プロセスの中心に配置する，APIライフサイクルツールです。ソフトウェアが実際に書かれる前に，開発者やアーキテクト，プロジェクトマネージャ，テクニカルライタといった人たちがコントリビュートすることを意図しています。
ソフトウェアライフサイクルはGitHubと統合されていて，Swagger InflectorなどのツールをAPIの実際の実行時ソースとして使用可能です。プライベートAPI機能が間もなくお目見えする予定ですが，社内ではすでに2000以上のAPIで利用されています。
InfoQ: 今年初めのGoogleによるgRPCの発表のように，WebではRPCが改めて注目されているように思えますが，この状況をどのように思われますか？
Tony: 単にAPIを利用したいだけで，実現方法には関心のない場合が多いのではないかと思います。使いやすい，よいAPIを作ることが非常に難しい問題であるのは事実ですが，APIの採用が成功する上では，クライアントの実装とAPIへのアクセスこそが最も重要なファクタなのです。
大部分のSDKでは，APIを事実上のRPCのように扱うことで，ベースとなるプロトコルをエンドユーザから抽象化しています。ですから，ほとんどの場合，APIがRESTfulかどうかは問題にはなりません。
潜在的に複雑なリモートシステムを，SOAPサービスのようなすべての要求を処理する単一のエンドポイントではなく，分離した複数の部品によって構成する上で，十分に考えられたRESTful URL構造を備えることは極めて重要だと思います。
REST設計では，API内部は必然的に分離的な構造になります。AWS Lambdaなどのツールを見れば，ビジネスロジックの小さなコンポーネントが個々のエンドポイントに対応するようなREST形式の構造に最も適していることが分かります。ですから，RESTは今後も重要ではあると思いますが，ユーザの観点からはあまり問題にはならないのではないか，というのが私の意見です。どちらかと言えば，プロバイダ側の問題です。
InfoQ: 一般論として，SwaggerとREST APIはマイクロサービスに適していると思われますか，あるいはもっと最適化されたプロトコルが必要になるのでしょうか？
Tony: Swaggerのような記述形式は，強固なマイクロサービスフレームワークには不可欠です。RESTがパフォーマンス的に不十分な例というのは，あまり見たことがありません。そういったケースもあることは間違いありませんが，どのようなプロトコルが適切であったとしても，JSONやProtocolBufferなどを使用したAPI定義が必要なことに変わりはないでしょう。
InfoQ: 先日のインタビューでDaniel Jacobson氏が，エフェメラル(ephemeral)APIにおけるAPI形式記述言語の価値について疑問を呈していました。彼の言うことは事実で，例えばSwaggerを使用したようなAPIの形式指定が適さないケースが他にもあると思われますか？
Tony: APIが短命(ephemeral)なのであれば，それを形式的に記述して自動的に処理できることが，より一層重要になります。さまざまな処理を独立的に実行するサービスが多数存在する中で，それらを利用するクライアントSDKの開発を手作業で続けるのは不可能だからです。
長期にわたって利用される静的APIでは，静的なドキュメントと手作業で開発したクライアントを使い続けることができますから，ラピッドバージョニングやエフェメラルサービスでは，形式的定義がこれまで以上に必要になります。
InfoQ: あなたの経験から，コードファーストとAPIファーストを採用する開発者の割合はどの程度だと思われますか，また今後数年ではどの程度変わると思われますか？
Tony: 企業や業界の成熟度によって変わってくるでしょうね。開発者の数だけを純粋に見れば，ほとんどがコードファーストということになると思います。
今後開始されるプロジェクトでは，ツーリングや改良されたライブラリ，デザインファースト向きの機能などのおかげで，開発プロセスは仕様ファーストな開発へと徐々に移行していくでしょう。
Swagger仕様は現在，少なくとも３つのプロジェクト(Swagger Inflector, Swagger Node, Zalando Connexion)をサーバで立ち上げるために必要になっています。今後すべてのAPIがこのような方向に進むことになります。仕様とは，ビジネスロジックのためにエンドポイントに接続するライブラリが使用する，事実の資料でありDSLなのです。
来年はおそらく50%のAPIを仕様から着手すると思いますが，それにはサーバ側のワークフローの対処が必要になります。仕様をルーティングロジックとして仕様する新しいツールが，サーバ用に静的コードを生成する方法を徐々に追い抜くだろうと期待しています。
InfoQ: プライベートAPI規約の設計は，APIプロバイダとユーザのどちらが行なうべきでしょうか？
Tony: 両方ですね。コラボレーションが必要です。ユーザがプロバイダにフィードバックを提供して，APIを改善していかなくてはなりません。私の見解としては，ユーザがユースケースを主導して，サーバ設計者がそれに実用性を加えるべきです。設計プロセスは両者の共同作業であっても，最終的にはユーザのニーズを最優先に満足することが必要なのです。
免責事項: 本記事の著者が勤務するRestletは，Web APIプラットフォームプロバイダとしてOAIに参加しており，SwaggerやRAMLなどいくつかのWeb API言語をサポートしている。