昨日、RAMLの開発元であるMuleSoftが、Open API Initiativeへの参加を発表しました。SmartBear Softwareによって作成され、非常に人気のあるSwagger SpecificationをベースにしたOpenAPI Initiativeは、Adobe、IBM、Google、Microsoft、Salesforceを含む20以上のメンバーが参加するLinux Foundationプロジェクトです。
API業界のフォロワーにとって、これはOpenAPI Specification (OAS) への明確な収束の兆候であることは明らかでしょう。RAMLはOASの上にさらなるモデリング機能を提供し続けるでしょうが、最終的に「契約」はOASを介して行われる可能性が高いです。現在Oracleの一部であるApiaryは、2016年にOpen API Initiativeに参加し、OASを彼らのドキュメント中心のBlueprintフォーマットのバックエンドとして採用しました。
Swagger (OAS) はどのようにして標準になったのか？
振り返ってみると、疑問は、「軽量でコミュニティに根ざしたOAS（Swaggerを介して）は、2013年から2015年の間の「偉大なAPI記述戦争」から、いかにして主要なフォーマットとして台頭したのか？」ということです。（そして、Swaggerが2015年初頭にSmartBearに移管されるまで、正式な企業からの支援がなかったのに、なぜそうなったのでしょうか？)
マーケティング、ツール、(確かに素晴らしい)名前などがありますが、これらの要因をすべて無視して（それは容易ではありませんが）、仕様そのものに焦点を当てると、Swaggerがこの戦争に勝ち、他の仕様がそれに収束した明確な理由があります。
Swaggerは少数の目標をもって始まりました。そして、すべてのユースケースをカバーすることは、その目標の一つでは決してありませんでした。それにより、Swaggerの創設者たちは、3つのシンプルな目標をもってプロジェクトを構築しました。
- 人間が読めること。つまり、仕様は簡潔で、整理され、そして「普通の」人が理解できるほど明確でなければなりませんでした。
- 機械が読めること。これには、コンピュータが仕様自体を解釈して「何か有用なことを行う」ことができるような構造と「ルール」が必要でした。
- REST APIを消費または生成するために必要なすべてを記述するのに十分徹底していること。
初期の1.0 Swagger Specificationには欠点がありましたが、上記のルールに確かに従っていたため、それを利用するための非常に堅牢で価値のあるツールを構築することができました。
これは、当時の他の2つの主要なフォーマットとどう違うのでしょうか？
シンプルです。
- API Blueprintは非常にクリーンなドキュメント形式です。人間向けであり、Markdownに限定されています。後に、異なる形式で作成できるようにツールが開発されましたが、これは明らかに「記述」よりも「ドキュメント」に焦点を当てていました。違いは何でしょうか？それは、法律文書の要約を読むのと、文書自体を読むようなものです。ドキュメントとしては人気がありますが、機械が読める構造、厳密なスキーマ、「実用的な拡張機能」という概念は、Markdownとはうまく機能しないようです。
- RAMLの「ML」は「モデリング言語」を意味します。これは、RAMLの設計目標が、多数のAPIをモデリングする能力にあることを意味しますが、これは特定のAPIや開発者が必要とするものとは限りません。彼らが皆必要としているのは、契約を曖昧さなく機械が読める方法で記述するための、合意された方法です。
これは今後何を意味するのでしょうか？
たくさんあります！しかし、1990年代後半のブラウザ戦争のように、APIの記述のための単一の言語への収束が見られると私は信じています。これは良いことです（私たちの中には、「このサイトはNetscape Navigatorでのみ動作します」というメッセージを覚えている人もいます）。最終的に、APIの利用者は、それがどのように記述されているかを気にしないのが普通だからです。メカニズムが標準化され、より多くの「もの」が通信できるようになれば、誰もが利益を得ます。
業界がOASを中心に結束しているのを見るのは喜ばしいことです。RAML APIの仕様をOAS契約として表現できるようになった今、APIエコシステム全体でこれらの契約から最大の価値を引き出すことができ、機械間通信の合意を形成し、そして重要なことに、APIライフサイクルを推進することができます。
私たちは多くの公開討論を行い、プロジェクトに数千時間の個人的な時間を費やしました。最初に正しい目標を設定することが、RESTコミュニティの心をつかむ鍵であることが判明し、その結果、MuleSoftのRAMLチームと協力して、現在のOASの取り組みにおいて彼らの専門知識を活用できることを楽しみにしています。
[caption id="attachment_694" align="aligncenter" width="310"]
2013年のAPIフォーマット大戦争中にRAMLの生みの親であるUri Sarid、API Blueprintの生みの親であるJacob Nestril、Swaggerの生みの親であるTony Tamとの数々のIPA燃料公開討論の一つ[/caption]
更新: この記事は、いくつかの事実関係を明確にし、潜在的な誤解に対処するために更新されました。