目前，有三個主要的HTTP API規范在競爭：Open API Initiative（OAI）基于Swagger所提供的Open API Specification（OAS）、MuleSoft作為主要貢獻者的RAML以及Apiary所支持的API Blueprint，Apiary公司今年已經被Oracle收購。這三個規范都有自己的優點和相關工具，但是在2015年Swagger托管給Linux基金會之后，OAS獲得了社區的主流支持。OAS從一開始就得到了3Scale、Apigee、Google、IBM、Microsoft、PayPal以及其他廠商的支持。
HTTP API領域在未來將會如何演化尚不明晰，但是最近發生了一些很有意思的事情。其中有一件事就是MuleSoft最近宣布加入OAI。MuleSoft的CTO同時也是RAML的創建者Uri Sarid已經開始參與OAI技術開發者社區并認為“每個人都應該支持一種通用的格式，它至少要能夠描述API的服務模型”，這種格式應該是“目前采用最廣泛的，即OpenAPI規范。”
鑒于MuleSoft依然“致力于支持RAML倡議及其投資，并且在擴大該生態系統”，我們可以得出結論，Sarid在OAI TC的主要目的是推動OAS的開發采納RAML目前已經支持的一些特性：API建模、支持模塊以及分離API協議的關注點。至于OAI TC會從RAML上借鑒多少內容尚有待觀察。為此，MuleSoft已經開源了API建模框架，這是一種與API交互的方式，還包含對API的建模，以及隨后生成RAML或OAS文檔。實際上，我們可以將RAML定義的API，對其進行解析并生成相應的OAS文件。
MuleSoft的API建模框架依然是“alpha”和“實驗性”階段，Restlet是OAI的初始成員之一，最近又加入了RAML工作組，發布了新版本的Studio，能夠同時支持OAS和RAML。Restlet的創始人Jerome Louvel闡述了RAML對OAS的影響：
與其讓這三種方案進行直接的競爭，我們還是希望其中有一個能夠獲勝，取代另外的兩個，有必要也有可能采用一種更好的演化路徑。這個過程中的主要參與者和構建工具，比如Restlet Studio，同時支持OAS和RAML，并且會傾聽用戶的需求，我意識到理想狀況是讓Apiary和MuleSoft加入Open API Initiative，并逐漸做出貢獻，使其變得收斂，而不一定要將這三個規范合并在一起...
在即將發布的OAS 3.0之上，我設想未來的RAML釋放版本會擴展OAS規范，以捕獲目前通過RAML 1.0表述的API建模信息。它將會讓OAS核心更加簡單和專注，同時還能夠讓API建模工具之間實現更好的交互，有助于保護API團隊在設計之時所做的投資。Restlet是OAI的創始成員，最近又加入了RAML工作組，我希望能夠直接為這些目標作出貢獻。
確實，Apiary去年加入了OAI，并且為他們的工具添加了對Swagger的支持。HTTP API領域似乎正在圍繞OAS進行整合。這意味著將來會有一個API規范，用戶創建互操作的API會更加容易。至于RAML和API Blueprint會對OAS帶來多大的影響，尚有待觀察。
查看英文原文：The HTTP API Space is Consolidating around OAS
京公網安備 11010502049343號