API言語は揺籃期にある。その開発者たちは先駆者であり，それぞれの仕事に最適な技術を選択している。今年初めにInfoQは，API仕様の選択肢に関してHacker Newsで交わされた，活発な議論を取材した。
コミュニティでの議論から分かるのは，ただひとつの標準というものは存在しない，ということだ。API開発者たちはAPI BlueprntやRAML，Swaggerなどを積極的に利用すると同時に，コミュニティとして協力して，将来使用される標準の定義に取り組んでいるのが現状だ。
InfoQは先日，ApiaryのCEOであり，API Blueprintプロジェクトの創始者でもあるJakub Nesetril氏と話す機会に恵まれた。
InfoQ: API Blueprintの目的と，開発のきっかけについて教えて頂けますか？
Jakub Nestril: API Blueprintは RAMLより早く生まれました。Swaggerの初期の頃です。SwaggerはWADLに非常によく似ていますが，API Blueprintはもっとシンプルで，人が読み書きしやすいフォーマットであることを重視しました。
Apiaryのプラットフォームが生まれたのは，週末のハッカソンがきっかけです。フォーマットを探していた私たちは，そこでさまざまな選択肢を見たのですが，どれも非常に複雑でした。そこで次の１年を費やして，本当にシンプルで魅力的なAPIの記述方法を開発したのです。
InfoQ: API Blueprintの最新バージョンは数週間前にリリースされた1A8ですが，今回のバージョンの主な拡張について説明してください。
JN: マークダウンのネイティブなデータ型の参照と再利用，サポート強化に力を入れています。1A8の大部分は，マークダウン構文のオブジェクト表記であるMSONです。これはJSONスキーマの簡易版です。開発者が楽をできるように，人が簡単に読み書きできるような簡略なものを目標にしました。JSONスキーマとは100%の互換性があります。実際にバックエンドでは，JSONスキーマにコンパイルされています。
InfoQ: 仕様変更や関連ツールのリリースは，どのように管理しているのですか？
JN: 最初に言語をリリースします。完全なMITライセンスで，すでに多くのコントリビュータもいます。 言語のアップデートを数ヶ月前に連絡した上で，最初にパーザを更新します。その後2週間程度，Apiary社内で利用して確認を行います。
InfoQ: Swaggerの後援がReverbからSmartBearに代わりましたが，これについてはどう思いましたか？
JN: SmartBearの新たな後援は歓迎しています。Tory Tam氏がSwggerプロジェクトに残ったのもよかったと思っています。API開発へのデザインファーストのアプローチの注目度は，私たちを含むすべてのAPIベンダにとって無視できないものになっていますから。
Apiaryは常にAPIツール企業です – API Blueprintは私たちにとって，開発チームや製品チームにシンプルさを提供するための手段なのです。その他のフォーマットも同じ世界観に集まりつつあるのには，まさに感動を覚えています。場当たり的なツールを使って開発していた石器時代から，API産業が今まさに抜け出そうという，その力になっているのですから。
Ole (SmartbearのCTO)とはこれまでにも付き合いがありましたから，この良好な関係を今後も続けたいと思っています。
InfoQ: Swaggerコミュニティには，今後プロジェクトが前進する上で，最も相応しいオープンガバナンスモデルに関する議論があります。API Blueprintのガバナンスモデルや組織，オープン性や効果のレベルについて，詳しく説明して頂けますか？
JN: API Blueprintは適応範囲の広いMITライセンスを採用していますから，最もオープンな記述形式を持っているといえます。私たちは意識的にオープンコミュニティを育てて，言語の意図的な変更や展開を行う何ヶ月も前から事前通知を行ってきました。また，コミュニティからのコントリビューションは，基本的にすべて受け入れています。
私たちの現在のモデルがボトルネックだとは思いませんが，Swaggerはもっと多くのベンダが関与していますので，よりフォーマルなガバナンスモデルが必要なのかも知れません。SmartbearはおそらくSwaggerのガバナンスモデルで，“オープンはいかにオープンか”を把握しようとしている段階なのではないでしょうか。APIコミュニティが前に進もうとする動きに参加できるのは，私たちにとって幸運ですね。
InfoQ: RAMLでは，コレクションリソースのページネーションで使用するクエリパラメータのように，横断的なAPIを記述する手段として，トレイト(Trait)とタイプ(Type)という概念を導入しています。API Blueprintにもこのような機能はありますか？
JN: ありますが，アプローチが多少異なります。トレイトは一般的に，API間の一貫性を支援するショートカットとして利用されていますが，すべての継承ルールとオーバラップする宣言をインテリジェントに投影しなければならないため，オーサリングプロセスが複雑化しています。
API Blueprintでは，生成や利用が簡単であることを重視しています。そのために，それ自身で複雑なデザインパターンをサポートしようとするのではなく，アーキテクチャ的な監視機構の部分については，API Blueprint Assertion言語として分離する手法を採用しています。これによって，他の製品ではプログラム的に処理しなければならなかったAPIスタイルガイドの定義が，言語で記述できるようになりました。これをApiary for Enterpriseとして，昨年の秋に導入しています。現在はこれを，より広くロールアウトするプロセスの最中です。
InfoQ: Swagger v2.0やRAML v0.8と比較した時，API Blueprintの最大の強みは何でしょう？
JN: API Blueprintは最もヒューマンフレンドリなフォーマットです。開発者やプロダクトマネージャ，ドキュメントライタ，アーキテクトといった人たちに広く利用されています。最大の強みは，このすべてを同じテーブルで提供できることです。
InfoQ: 最終的には，これらAPI言語のどれかが勝利することになるのでしょうか，あるいは関連する複数の言語の混在する余地があるのでしょうか？API BlueprintがAPI定義のデファクト標準になる可能性はどのようなものでしょう？
JN: 私が今注目しているのは，言語が収斂しつつあることです。 API Blueprintを手がけ始めた頃，Swaggerはまだ非常に初期の段階で，私には複雑過ぎました。ですがその後は，私たちがオープンソースコミュニティで大々的に行ったように，シンプル化に向けて大きく進歩を遂げました。ですから私は，この２つが収束する可能性があると考えています。そうならないとしても，両者の間で強い相互互換性が実現することは間違いないでしょう。
InfoQ: API Blueprintに関連して現れたコミュニティプロジェクトの中で，もっと興味深いのは何ですか？いくつか紹介してください。
JN: オープンソースのドキュメントレンダラとして有名なAglioですね。AWSの開発者が作ったものです。Lonely Planetの開発者が作ったVigiaも，API Blueprint用のRSpecアダプタです。OS X用の優れたネイティブAPIクライアントであるPawも，API Blueprintに強く統合されています。コミュニティツール全体としては，Subline TextやAtomやVimのプラグインからPostmanやcURLなどとの統合へという，明らかな徴候があります。その例の多さは，ここではとても言及できません。完全なリストは，API BlueprintのWebサイトで紹介しています。
InfoQ: API BlueprintのクライアントSDK生成は，何に対応しているのでしょう？
JN: 実はたくさんあります。API資料の一環として，15言語のコードスタブを開発しています。APIを使い始める上では，よい開始点となるでしょう。
もっと広い意味では，どのドキュメンテーションフォーマットであっても，SDKクライアントを静的に生成するのではなく，実行時に動的に自動構成できる可能性があります。その大きなメリットはAPI変更のライフサイクルであり，ハイパーメディアです。長期的に見た場合の正解は，コード生成よりも実行時構成だと思います。iOS用の汎用的な自動構成SDKであるHyperdriveを見れば，将来像が理解できると思います。本当に素晴らしいものです。iOSアプリにコンパイルした後，実行時にAPI Blueprint APIにリンクします – 変更の必要はまったくありません。API Blueprintを通じて自身のAPIを理解して，操作方法やAPIIコールのシリアライズ/デシリアライズ，それらを評価する方法を確認します。 モバイル開発者にとって，この作業は非常に大きいのです。
InfoQ: ハイパーメディアAPIの有用性については，どのようにお考えですか？API Blueprintはこの形式のAPIをサポートしているのでしょうか，あるいはその予定はありますか？
JN: ハイパーメディアAPIは，APIのバージョニングの単純化や，もっと重要な変更作業の操作の上で必要です。API Blueprintは多分，最も優れたハイパーメディアのサポートを備えていますが，それでも潜在的能力のごく一部に過ぎません。もっとよいものにするための，素晴らしいアイデアがたくさんあります。重要なのは，Mark FosterやStephen Mizelといったハイパーメディアを支える人たちが現在，Apiaryにいるということです。彼らはもちろん，ただ座っているだけではありません :)
InfoQ: API Blueprintを使用する場合，基本的な開発ワークフローはどのようなものになりますか？
JN: ワークフローでもっとも画期的なのは，APIバックエンドチームとAPI利用チームが，APIの両側で並行して共同設計，共同開発ができることです。Apiaryでまず最初に，モックサーバを構築した理由がここにあります。APIワークフローにTDDを導入したのも，私たちが最初です – 現在API Blueprintを定義すれば，APIを正確に実装するために，あるいは単にAPI資料をチェックするために，Dreddを利用することができます。時々冗談で，API資料のコードカバレッジを実現したのは私たちだ，と言っていますが。
InfoQ: APIコードファーストから，API定義ファーストへと進展した実例はありますか？
JN: たくさんあります。最初からそれを目標にしてきましたから，毎日たくさんの人たちが定義ファーストの価値を理解してくれるのは，本当にうれしいです。定義ファーストへの移行は，そのような定義から得られたツールの価値が高まることによって，さらに加速されています。毎月成長していますし，増加の一途です。
InfoQ: API Blueprintの今後について，InfoQの読者に伝えられることは他にありますか？
JN: MSONとデータ構造の追加，APIテストを可能にしたワークフローの実現，強力な認証サポートと再利用などの緊急追加といったものを，非常に嬉しく思っています。
10万人以上の開発者がAPI Blueprintを利用していますから，マークダウンそのものであると言って差し支えないと思います。
注: 本記事は全4回のAPI言語シリーズの一部である。 API言語に関する詳細や視点については，これらの記事を参照のこと。
- Community Debates API Specification Alternatives
- Swagger Founder Makes Commitment to Keep Project Open
- RAMLの創始者が語るAPIビジネス - ガバナンス，技術，買収
免責事項: 本記事の著者はRestletに勤務している。同社はSwaggerやRAMLなどのWeb API言語をサポートする，Web API プラットフォームのプロバイダである。