先の2月にInfoQは，API言語と仕様を巡る，コミュニティの活発な議論について報告した。記事の公開から約１ヶ月後，SmartBearが，代表的なAPI言語のひとつであるSwaggerに対する権利を獲得したと発表した。これによって議論は新たに，より活発な段階へと移行した。発表の直後，InfoQはSwaggerの開発者にインタビューして，Swaggerプロジェクトが今後もオープンであり続けるというコミットメントを確認している。
さらに先日，もうひとつの有名なAPI言語であるRAMLプロジェクトの創始者として有名な，Uri Sarid氏にインタビューする機会を得ることができた。MuleSoftのCTOでもある氏が，RAMLのテクノロジとガバナンスに対するコミュニティの理解を支援してくれたこと，SmartBearによるSwagger買収についての自身の見解や，RAMLとSwagger，API Blueprintの興味深い比較点を示してくれたことに対して，我々は深く感謝している。
InfoQ: RAMLの目的と，このプロジェクトでのあなたの役割について説明して頂けますか？
Uri Sarid: RAMLの目的は，APIそれ自体について語るための共通言語となることです。また，提供者と利用者の間で実際の取り決めを把握する方法としても最適です。参照だけでなく記述することも簡単で，人とマシン両方を対象とした，豊富な情報を得ることのできる方法で，それを実現したいのです。
私の役割は，そのオリジナルのアイデアを持っていたことです。既存のものが何か利用できないか，いろいろ探してみました。そうして見つかった選択肢のひとつがSwaggerでしたが，少なくともその時点のステージでは，あまり適したものではありませんでした。そこでMuleSoftからだけでなく，社外からも協力を得ることにしたのです。現時点では，私がリーダを続けています。
InfoQ: RAMLプロジェクトの主要な部分と言語仕様，それぞれの関連性について，詳しく説明して頂けますか？
Uri: 言語仕様は確かに中心ではありますが，ツーリングなしでは意味がありません。たくさんのコントリビュータから提供された，さまざまなツールがあります。MuleSoft所有のものもありますが，SmartBeanやOracle，Akana，Restletなど，他のベンダが提供しているものもあります。数多くの独立系開発者も，GitHub上でコントリビュートしています。非常にアクティブなユーザコミュニティもあり，個人開発者から大企業まで参加しています。
InfoQ: RAMLバージョン1.0が発表されたのは2014年10月でしたが，最初の公開バージョンである0.8がリリースされたのは，それから約1年経った後のことです。リリーススケジュールの主な変更点や今後の計画について，説明して頂けますか？
Uri: 体系的な変更を行ったのではなく，間違いをいくつか訂正したに過ぎません。提供されているサンプルがリソース/メソッド/メディアタイプ毎に１つのみだったのを訂正した，というような具合です。それ以外では，YAMLでJSONスキーマを指定する機能や，より多くのメタデータをキャプチャするためのRAMLの拡張といった，利用を容易にするためのものもあります。
2014年10月以降，たくさんのフィードバックがありましたので，近々バージョン1.0を提供できるはずです。現在はパーサの実装に着手したところで，数週間のうちに1.0の作業を完了できると思っています。ただし，このRAMLバージョン1.0を，単なるスペックとして公開するつもりはありません。プログラム的に適切なもの，すなわち矛盾がなく，正式に定義された，特にツーリングの開発が容易なものとして提供したいと思っています。
InfoQ: SwaggerのスポンサシップがReverbからSmartBearに譲渡されることに関して，どのように思われましたか？
Uri: とてもエキサイティングなことだと思います。Tony Tam氏はAPIの世界では偉大な先駆者ですが，私もSwaggerは，Reverbには荷が重いものになったと思っています。SwaggerとSwagger UIはもともと渾然一体となっていましたし，API仕様自体は中心的な存在ではなく，APIという概念そのものが確立していませんでした。RAMLが重視しているのは，そのAPIなのです。YAMLを基盤フォーマットとして選択したり，開発当初からAPI Designerを提供していた理由もそこにあります。SwaggerのAPIはUIの中間段階のような存在でしたが，徐々に整備されてきました。建設的な競合関係が存在することのメリットとして，SwaggerもYAMLフォーマットを採用しましたし，APIデザイナを用意して，よりAPI仕様をアピールする存在になっています。経験豊富で革新的なツールベンダとして，SmartBearの手腕には大いに期待しています。彼らと密接な協力関係を続けられることが今から楽しみです。
InfoQ: Swaggerコミュニティの中には，プロジェクトとして最高のオープンガバナンスモデルについての議論があります。RAMLのガバナンスモデルと組織，オープン性と有効性について，もう少し詳しく説明して頂けますか？
Uri: APIあるいはAPI管理について考えるとき，最初に明確にしておかなくてはならないのは，RAMLにそれだけの価値がある，ということです。なによりもまず，ガバナンスの対象として相応しいものがなくてはなりません。私たちには信念がありましたが，人々がこれにどのような用途，適用，価値を見出すかを知りたかったのです。現在では私たちの期待したものに比べて，信じ難いほど多くの価値が見出されています。
それに伴って，APIに適切なガバナンスモデルとは何かを考える必要があります。ですが，本格的な委員会組織のような，形式的で重苦しいものにはしたくありません。WSDLのような失敗はしたくないのです。継続的な進歩を達成して，価値感に対する議論をオープンにするにはどうすればよいか。オープン性については100%です - プロジェクト自体オープンソースですし，コミュニティとのディスカッションはすべて，公開された透明性のある形で処理されています。
SmartBearに面白いガバナンスモデルがあるのならば，Swagger 2.0の進捗も見ながら，そこから何かを学びたいと思いますし，Ole Lensmar氏(SmartBearのCTO)とのブレインストームもしてみたいですね。
結局のところ，まずは重要な価値を創造した上で，その価値を保護するためにガバナンスを適用することが重要だと思います。ガバナンスそれ自体が価値を生み出すのではないのですから。
InfoQ: RAMLでは，収集リソースのページネーションのためのクエリパラメータのように，APIの横断的な面を説明する手段として，トレイトとタイプという概念を導入しています。一方でSwagger 2.0では，参照というコンセプトがJSONおよびYAMLのレベルに存在します。この２つを比較して，どのように思われますか？
Uri: まったく違うものだと思います。単純な参照としては，RAMLにもインクルードとポインタがあります。根本的な違いは，仕様の一部がローカルなのかリモートなのかという問題ではなく，再利用性ないし一貫性に必要な構造が何であるか，どのパターンが使いやすく，また推奨されるべきなのか，という点にあります。
トレイトは振る舞いを扱うもので，構造化(ミックスイン)できます。タイプはクラスやオブジェクトといったもので，継承することが可能です。リソースタイプとAPI動作に関して再利用可能なパターンを見出すことは，APIエコシステムにおいて重要な概念だと思います。ですから私たちは，APIの内部においても，あるいはAPI間においても，より一貫性を持つことができるように働き掛けています。結果としてそれがAPIの使いやすさ，さらにはAPIエコシステムの加速へとつながるでしょう。
一般的なプログラミングの概念に沿うことも必要です。Swaggerの参照(RAMLではインクルード)はインポートと等価な機能で，コードを複数のファイルに分割可能にするものです。これに対して，リソースタイプやトレイトはクラスを扱うもので，より高いレベルのモデル構造を提供します。
InfoQ: Swagger v2やAPI Blueprint v1と比較したとき，RAMLの主な強みとなるのは何でしょう？
Uri: トレイトやタイプはそのひとつだと思います。その他の違いとして，RAMLの構文は非常にクリアです。SwaggerやAPI Blueprintでは，APIの構造がこれほどクリアであるとは言えません。RAMLでは，APIに構造があります。これらのAPIの間には，クリアさのレベルで定性的な差異があります。
ドキュメント化をより重視しているAPI Blueprintに比べると，Swagger 2の方に多少近いのではないかと思います。
最後にドキュメントについて。私の考えるドキュメントとは，仕様から生み出されるアーティファクトです。一般的に，まずドキュメントから始めたいとは思わないでしょう。最初は仕様から始めて，そこからドキュメントを生成する方がよいと思いますね。
InfoQ: 最終的には，これらAPI言語のどれかが勝利することになるのでしょうか，あるいは複数の関連言語が存在する余地があるのでしょうか？RAMLがAPI定義のデファクト標準になるためには，どのようなチャンスがあるのでしょう？
Uri: 未来を見る水晶玉は持っていませんが，ワーキンググループのメンバと一緒に，RAMLの開発を積極的に進めています。ベンダ中立であることが重要です。ベンダには自分たちの都合があって，それはプロジェクトに沿うものである場合も，そうでない場合もあることを認識しておかなければなりません。SmartBearのようなベンダがSwaggerを所有するということは，APIコミュニティにとって最高の利益になるに違いありません。同じように，MuleSoftの利益はRAMLに沿ったものであって，MuleSoft独自のものではありません。SmartBearも状況は同じだと思いますので，Swaggerはよいスポンサを得たと思っています。
統合もあり得るでしょう。SOAPがWSDLひとつに集まったようにですが，ただしその結果はモンスターが生まれただけです。ひとつのAPI言語が勝利すれば，おそらくはそれがモンスターになるでしょう。Swaggerがバージョン2.0をローンチした動機もそこにあると思います。それは素晴らしいことだと思いますし，Swaggerの改善に協力もしました。私たちはお互いに，コミュニティの利益のためにチャレンジしているのです。
Jakub Nesetrill氏(API Blueprintの作者)とも考えは同じです。私たちは競争し，結果としてどちらも改良されています。RAMLの成長は非常に良好だと，私たちは思っています。
InfoQ: RAMLに関連して登場したコミュニティプロジェクトの中で，一番興味深いのは何ですか？
Uri: 私が興味を持っているのは，プロジェクトの幅と多様性に関する面です。静的なコードジェネレータやクライアントジェネレータ，サーバジェネレータ，あらゆる種類のフォーマットとの相互変換を行うコンバータ，多くの言語やフレームワーク(私が聞いたことのないものもあります)で動作するパーザなどのツール，テストフレームワーク，ブラウザやエディタのエクステンションなどがあります。さらには，APIデザイナとNode.jsフレームワークを組み合わせたモック生成サービスのように，他のツール上に構築したツールも登場しています。
InfoQ: クライアントSDKを開発する点については，RAMLでは何を提供する必要があるのでしょう？
Uri: すでに現在，テンプレートを使ってこれを行う，クライアント自動生成フレームワークがあります。ですからRAML定義や，それに従って言語あるいはフレームワーク特有のテンプレートをアクティベートして，その言語ないしフレームワーク用のクライアントを生成するための中心的ロジックはすでに存在しているのです。これらのテンプレートを書くかどうかは，コミュニティにおける私たち次第です。すでにJavaScriptとNode.jsのものと，Python用のものがあります。現在開発を行っている人たちも知っていますから，さらにいくつかが近々現れるでしょう。それらとは別に，Visual Studioに統合された.NETクライアントジェネレータや，RAML-for-JAX-RSオープンソースプロジェクトの一部として，Java用のクライアント(およびサーバ)ジェネレータもあります。
InfoQ: ハイパーメディアAPIの有用性については，どのようにお考えですか？RAMLでこのスタイルのAPIをサポートしている，あるいはそうする計画はありますか？
Uri: 私個人としては，まだ結論が出ていません。よくできたAPIもありますが，まだ一般的ではないと思います。その世界のリーダたちとは興味深い議論を延々と続けていますが，議論はまだ尽きていない，というのが現時点での結論です。
ハイパーメディアAPIは企業に対して，そのクライアントを記述するという深刻な課題を提起します。その一方でハイパーメディアAPIは，堅牢なAPIを作る方法として，極めて興味深いものでもあります。堅牢なAPIの構築は，この世界においてもっとも重要な課題のひとつなのです。その理由は単純です。もしも数百というAPIに依存していて(珍しいことではありません)，それぞれのAPIが1年に1回のみ大きく変更されるとすれば，結果的には，互換性を損なう変更が毎日行われていることになります。これは取り組むべき，重要な課題だと思います。
現在のRAMLには，ハイパーメディアをサポートするものも，その使用を阻害するものも，特にありません。ハイパーメディアアフォーダンス(affordance)のRAMLへの統合についてはいくつかの案がありますが，フォーマットに束縛されない形でそれを行う方法がまだ見つかっていないのです。しかしながら，すでに何人かがそれを行っているのですから，RAMLにそれを取り込み可能であることは分かっています。
InfoQ: これまで見てきたRAMLベースの開発ワークフローには，主にどのようなものがありますか？
Uri: ひとつは明らかに,APIデザインファースト・ワークフローです。非常に効果的であることが立証されていて，一度このアプローチを採用したら，以前の状態には戻りたくないでしょう。このアプローチを実践する人たちは，当初は既存APIのコードファーストを続けるかも知れませんが，最終的にはAPIファーストに移行します。
もうひとつは，すでのAPIを持っているのでデザインファーストのアプローチよりもアノテーションを利用したい，あるいはRAMLの設計を手動で取り込んでツールチェーンを活用したい，といった考えの人々のためのものです。そのような人たちはAPI Notebookを使用して，APIコールのユースケースをキャプチャするのがよいでしょう。
InfoQ: APIコードファーストから，API定義ファーストへと進展した実例はありますか？
Uri: 企業内部ならば，あります。最初にコードがあって，その後アノテーションを追加するという手順は，彼らにとってごく自然なものなのです。しかし，彼らがAPIをファーストクラスの市民として認めるようになれば，次バージョンのAPIの定義にはAPI Designerを使うようになるでしょう。
このような例は何度も見てきましたが，既存の開発者にとっては難しいことから， 変化が徐々に起きる場合もあります。彼らが新たにプロジェクトを開始する時に，まずAPI定義から始めればよいのです。
InfoQ: RAMLの今後に関して，公表できるものは何かありますか？
Uri: 公開後の1年間は，RAMLにとって非常に貴重な時間でした。これまでに数多くの成果がありましたが，潜在的なものについては，大部分がまだこれからです。ユーザがRAMLに求めるテーマ(おそらくはSwaggerにも)は，すでに記述されて，意図的に設計されたAPI仕様のメリットへと傾いています。
もっと高レベルの構成を行うことは可能でしょうか？それによってAPI設計はもっと簡単で，より強力なものになるでしょうか？より多くの参加者に対して開かれたものになるでしょうか？現在のRestlet Studioには，API設計をもっと簡単にする手段が用意されていて，さらに多くのものを自動生成することができます。それがRAMLの目指している方向なのです。
開発者ができる限り少ない作業で大きな価値を生み出すことのできるバリューチェーンが完成すれば，そこから離れることはできなくなるでしょう。近日中に公開されるRAMLで，そのようなものを探してみてください！
RAMLやSwagger，あるいはAPI産業の変化に対する意見があれば，下記にコメントを残してほしい。
免責事項: 本記事の著者はRestletに勤務している。同社はSwaggerやRAMLなどのWeb API言語をサポートする，Web API プラットフォームのプロバイダである。