Mulesoft が Open API Initiative に参加：Swagger と OAS から何を期待すべきか

2017年4月25日

2017年4月24日、Mulesoft が Open API Initiative に参加するというニュースが発表されました。Mulesoft は、API 設計のための記述形式である RESTful API Modeling Language (RAML) の提唱者です。Mulesoft が OAI に参加したことは、ソフトウェア業界が Swagger/Open API Specification (OAS) に収束していることを示唆しています。この機会に、OAS の歴史と将来に期待できることについて少しお話したいと思います。

始まり

API 定義/仕様は API ライフサイクルの重要な側面となり、計画から廃止までのあらゆるフェーズに影響を与えます。WADL は RESTful サービスを記述するための XML の主要な記述形式でしたが、人間が使いやすく読みやすい選択肢ではありませんでした。 2010年に登場した Swagger は、API のコントラクトを定義する、機械と人間が読みやすい記述形式です。このコントラクトは、リソースとサービスによってどのようなデータが公開されるか、クライアントがこれらのリソースをどのように呼び出すべきかを定義します。このアイデアはシンプルに見えますが、サービスが多くの言語で構築され、さまざまなデバイスのクライアントによって消費されるマルチプラットフォームの API エコノミーにおいて、強力な意味を持ちました。Swagger の作成者である Tony Tam は、Swagger 仕様の目標を最近の Swagger ブログの投稿で思い出しました。

人間が読みやすいこと。つまり、仕様は簡潔で、整理され、"普通"の人が理解できるほど明確である必要がありました。
機械が読みやすいこと。これにより、コンピュータが仕様自体を解釈して「何か有用なこと」を実行できるように、構造と「ルール」が必要でした。
徹底していること。REST API を消費または生成するために必要なすべてを記述できるほど、徹底している必要がありました。

オープンソースの Swagger 仕様の人気に伴い、他の記述形式がリリースされました。API Blueprint は 2013年にリリースされ、使いやすさと人間が読みやすいドキュメントの提供に焦点を当てました。RAML は、開発者がコードを書く前に API をより良くモデリングおよびプロトタイプ化できるというニーズに基づいて開発されました。これらの記述形式は、それぞれ Apiary と Mulesoft によって推進されました。実践者と消費者の間で、最適な記述形式について活発な議論が繰り広げられました。そして 2015年、Swagger 仕様は、形式の採用と開発を標準化するために、Linux Foundation の下にある Open API Initiative に SmartBear Software によって寄贈され、OpenAPI Specification (OAS) と改名されました。IBM、Microsoft、Google など、多くの業界の巨人がこのグループに参加しています。最終的に、Apiary と Mulesoft は OAI に正式に参加し、受け入れられる API 仕様に関する議論は終結しました — 業界が求めていたのは Swagger でした。

何を期待すべきか？

OAS のさらなる開発と標準化のために、RAML と API Blueprint の背後にある企業を含む多くの有力企業が OAI に参加したことで、API 記述の未来には革新的なブレークスルーが期待されます。以下に、仕様が進化するにつれて私が期待する点を示します。

開発者エクスペリエンスへの注力

OAS は、API がどのように動作すべきかについてすべてのステークホルダーを同期させることで、開発チームの生活を楽にします。しかし、結局のところ、API はその消費と同じくらい優れているにすぎません。Swagger UI は、開発者が OAS ベースの API のドキュメントを生成する最も簡単な方法ですが、常に反復して改善することができます。仕様が進化し続けるにつれて、Swagger UI の従来の機能を越えて、HTML や PDF などのさまざまな形式で優れたドキュメントを生成するなど、OAS のドキュメント作成機能の改善に重点が置かれることを期待しています。

持続可能性への注力

RAML は常に長期的な API 設計と持続可能性に重点を置いてきました。RAML の開発者が OAI に参加したことで、OAS が持続可能な設計をサポートするように進化し、開発者が長期的なスケーリングのために従来の REST に準拠していないプログラミング言語を利用できるようになることを期待しています。また、包括的な RESTful 設計を維持しながら、コントラクトのより柔軟なプロトタイピングオプションも登場するかもしれません。

イノベーションへの注力

OAI のすべてのメンバーは、さまざまなテクノロジー分野におけるイノベーションと破壊に多大な投資をしていることで知られています。より多くの意見を持った企業やインフルエンサーが OAI に参加するにつれて、API 記述市場におけるより良いイノベーションにつながる健全な議論や会話が行われる可能性が高まります。OAS の次のバージョンは、すでにリンキング (ハイパーメディア API に最適)、リソース間での複数のセキュリティフロー、より簡単なリクエスト/レスポンス形式など、いくつかの優れた機能をサポートしています。 API 設計およびドキュメントツールはすでに OAS への移行を進めています。今日、Swagger チームは、OAS を実装するためのオープンソースツールの次のフェーズを提供することに引き続き投資しています。人気の Swagger Editor と UI は、ゼロから再設計され、コードが単一の統合されたコードベースにマージされました。これにより、オープンソースプロジェクトでの作業と貢献が容易になります。この統合されたエクスペリエンスは、開発者とエンドユーザーが OpenAPI Specification で記述された API を設計、エンジニアリング、消費するための共通のフレームワークを確立し、今年後半にリリースされる将来の OpenAPI Specification 3.0 との互換性の基礎を築きます。 Swagger と同じチームが主導する SwaggerHub は、OAS/Swagger 仕様を使用して API を構築する際の組織のニーズを念頭に置いて構築されました。SwaggerHub は、チーム全体が OAS を使用して API のライフサイクル全体で作業できる中央プラットフォームを提供します。このようなツールがどのように進化し、OAS に新しい機能が追加されていくかを見るのは楽しみです。 Swagger の進化に関する詳細については、Tony Tom による Swagger.io ブログの最新記事「MuleSoft Joins the OpenAPI Initiative: The End of the API Spec Wars」をご覧ください。