HTTP APIはOASに統合へ

MuleSoftがOAIのメンバーになり、RAMLとOASの両方に対応するAPI Modeling Frameworkをリリースした。Restlet Studioは、新たにRAMLをサポートした。

現在、３つの競合するHTTP API仕様が存在する – Open API Initiative(OAI)によるOpen API Specification(OAS) – Swaggerがベース –、MuleSoftを中心とするRAML、今年Oracleに買収されたApiaryの支援するAPI Blueprintである。3つの仕様にはそれぞれ独自のメリットと関連ツールがあるが、2015年にSwaggerがLinux Foundationに委託されたことで、コミュニティの支持はOASに集まっている。OASは初期の段階から3ScaleやApigee、Google、IBM、Microsoft、PayPalといった企業に支援されていた。

HTTP APIの世界が今後どのように進化するか、今はまだ明確ではないが、最近になって興味深い動きがいくつか現れている。そのひとつが、OAIにMuleSoftが参加したという先日の発表だ。MuleSoftのCTOでRAMLの開発者であるUri Sarid氏は、“誰もが少なくともAPIのサービスモデルを記述可能な共通フォーマットをサポートするべき”であり、“今日最も多く採用されているのはOpen SPI仕様である”という考えから、OAI Technical Developer Communityへの参加を開始したのだ。

MuleSoftは今後も“RAMLイニシアティブのサポートと、エコシステムへの投資を継続する”と述べていることから、OAI TCにおけるSarid氏のプレゼンスには、現在RAMLがサポートしているAPIモデリングやモジュール、API契約の概念的分離などの機能をOASがサポートするように、OAS開発者に働きかける目的があると結論づけられる。ただし、OAI TCがRAMLの機能をどの程度採用するかは、現時点では未知数だ。この目的を達するためにMuleSoftは、APIとのインタラクションとそのモデリング、RAMLないしOAS資料の生成を行なうAPI Modeling Frameworkをオープンソースとして公開した。これによって実際には、RAMLで定義されたAPIを解釈して、対応するOASファイルを生成することが可能になる。

MuleSoftのAPI Modeling Frameworkはまだ“アルファ版”の“試験的実装”だが、OAIの初期メンバであり、現在はRAML WorkgroupのメンバでもあるRestletは先頃、OASとRAMLの両方に対応した自社のStudioを新バージョンとしてリリースしている。創設者であるJerome Louvel氏は、OASに対するRAMLの影響を次のように説明する。

３つの活動が直接的な競合を続けて、最終的にひとつが勝って他の２つを置き換えることに比べれば、よりよい道が必要かつ可能になったのだと言えます。このストーリの主要な登場人物たちの間近で行なった、OASとRAMLの両方をサポートするRestlet Studioのようなツールの開発を通じて、私自身としては、ApirayとMuleSoftがOpen API Initiativeに参加して３つの仕様を段階的に統合することが理想であり、必ずしも統合する必要はないと考えるようになりました。

OAS 3.0のリリースを間近にして、将来的なRAMLリリースにおいては、RAML 1.0の現在のAPIモデリング情報をキャプチャするようにOAS仕様が拡張されると予想しています。OASの中核をシンプルかつ明確に保ちながら、APIモデリングツール間の相互運用性を向上し、APIチームの設計に対する投資の保護を支援します。RestletはOAIの創立メンバであると同時に、先週からRAMLワークグループにも参加していますので、そのような活動に直接的に貢献できることを楽しみにしています。

実際にApiaryは昨年からOAIに参加するとともに、自社ツールにSwaggerのサポートを追加している。HTTP APIはOASを中心に統合されることになりそうだ。これによってAPI仕様は将来的にひとつになり、相互運用可能なAPIの開発が容易になる。RAMLとAPI BlueprintがOASにどの程度影響を与えるかは、現時点では明らかではない。