目前，有三個主要的HTTP API規(guī)范在競爭：Open API Initiative（OAI）基于Swagger所提供的Open API Specification（OAS）、MuleSoft作為主要貢獻者的RAML以及Apiary所支持的API Blueprint，Apiary公司今年已經(jīng)被Oracle收購。這三個規(guī)范都有自己的優(yōu)點和相關工具，但是在2015年Swagger托管給Linux基金會之后，OAS獲得了社區(qū)的主流支持。OAS從一開始就得到了3Scale、Apigee、Google、IBM、Microsoft、PayPal以及其他廠商的支持。

HTTP API領域在未來將會如何演化尚不明晰，但是最近發(fā)生了一些很有意思的事情。其中有一件事就是MuleSoft最近宣布加入OAI。MuleSoft的CTO同時也是RAML的創(chuàng)建者Uri Sarid已經(jīng)開始參與OAI技術開發(fā)者社區(qū)并認為“每個人都應該支持一種通用的格式，它至少要能夠描述API的服務模型”，這種格式應該是“目前采用最廣泛的，即OpenAPI規(guī)范。”

鑒于MuleSoft依然“致力于支持RAML倡議及其投資，并且在擴大該生態(tài)系統(tǒng)”，我們可以得出結論，Sarid在OAI TC的主要目的是推動OAS的開發(fā)采納RAML目前已經(jīng)支持的一些特性：API建模、支持模塊以及分離API協(xié)議的關注點。至于OAI TC會從RAML上借鑒多少內容尚有待觀察。為此，MuleSoft已經(jīng)開源了API建?？蚣?，這是一種與API交互的方式，還包含對API的建模，以及隨后生成RAML或OAS文檔。實際上，我們可以將RAML定義的API，對其進行解析并生成相應的OAS文件。

MuleSoft的API建模框架依然是“alpha”和“實驗性”階段，Restlet是OAI的初始成員之一，最近又加入了RAML工作組，發(fā)布了新版本的Studio，能夠同時支持OAS和RAML。Restlet的創(chuàng)始人Jerome Louvel闡述了RAML對OAS的影響：

與其讓這三種方案進行直接的競爭，我們還是希望其中有一個能夠獲勝，取代另外的兩個，有必要也有可能采用一種更好的演化路徑。這個過程中的主要參與者和構建工具，比如Restlet Studio，同時支持OAS和RAML，并且會傾聽用戶的需求，我意識到理想狀況是讓Apiary和MuleSoft加入Open API Initiative，并逐漸做出貢獻，使其變得收斂，而不一定要將這三個規(guī)范合并在一起...

在即將發(fā)布的OAS 3.0之上，我設想未來的RAML釋放版本會擴展OAS規(guī)范，以捕獲目前通過RAML 1.0表述的API建模信息。它將會讓OAS核心更加簡單和專注，同時還能夠讓API建模工具之間實現(xiàn)更好的交互，有助于保護API團隊在設計之時所做的投資。Restlet是OAI的創(chuàng)始成員，最近又加入了RAML工作組，我希望能夠直接為這些目標作出貢獻。

確實，Apiary去年加入了OAI，并且為他們的工具添加了對Swagger的支持。HTTP API領域似乎正在圍繞OAS進行整合。這意味著將來會有一個API規(guī)范，用戶創(chuàng)建互操作的API會更加容易。至于RAML和API Blueprint會對OAS帶來多大的影響，尚有待觀察。

查看英文原文：The HTTP API Space is Consolidating around OAS