時間：2017-04-21 作者：Tony Tam

  昨天，RAML的建立者MuleSoft宣佈他們已經加入了OpenAPI倡議。OpenAPI是由SmartBear軟體公司建立的，基於廣泛流行的Swagger規範，它是一個Linux基金會專案，擁有超過20個成員，包括Adobe、IBM、谷歌、微軟和Salesforce。

  對於API行業的追隨者來說，這是顯而易見的，這是OpenAPI規範(OAS)上的一個清晰的訊號。RAML將繼續在OAS之上提供額外的建模功能，但是最終合同很可能是通過OAS來實現的。作為Oracle的一部分，Apiary在2016年加入了開放API專案，讓OAS支援他們的文件集中的藍圖格式。

Swagger (OAS)是如何成為標準的?

  回顧過去，問題在於，在2013年到2015年之間的“大API描述戰爭”中，OAS(經由Swagger)作為輕量級的，社會主流的格式，是如何形成的?(所有這些都沒有正式的企業支援，直到2015年初，Swagger 轉向SmartBear?)

  有市場營銷、工具、(當然是不可思議的)名稱等等，但是如果我退一步，忽略所有這些因素(這並不容易)，並且只關注規範本身，那麼就有一個明確的理由說明為什麼Swagger贏得了戰爭，而其他的則仰賴於它。

  Swagger是以少數幾個目標為起步的方向的——並且覆蓋每一個用例當然不是其中之一。在此基礎上，Swagger的開創之父為這個專案建立了三個簡單的目標:

• 人類可讀的。這意味著規範必須簡明、有條理、清晰，使“正常”的人能夠理解它。

• 機器可讀的。這需要結構和“規則”，這樣規範本身就可以被解釋為計算機“做一些有用的事情”。

• 要徹底地描述所有需要消耗或生成REST API的內容。

  儘管最初的1.0 Swagger規範有它的缺點，但它確實遵循了上面的規則，因此我們能夠構建非常健壯和有價值的工具來利用它。

這與當時的其他兩種主要格式有什麼不同呢?

簡單來說：

• API藍圖是一種非常乾淨的文件格式。它是為人類而存在的，被限制在markdown中。後來開發了工具以允許以不同的格式進行創作，但這顯然是側重於文件而不是描述。有什麼區別呢?這就像閱讀法律檔案的摘要和檔案本身一樣。雖然在文件方面很流行，但是機器可讀結構、嚴格的模式和“可操作的擴充套件”的概念似乎並不適用於markdown。

• RAML中的“ML”代表“建模語言”。這意味著RAML的設計目標是能夠對大量API進行建模，但這可能不是任何特定的API或開發人員所需要的。他們所需要的是一種商定的方式，以一種明確的機器可讀的方式來描述契約。

這意味著什麼呢?

  很多!但就像20世紀90年代末的瀏覽器大戰一樣，我相信我們將會看到統一的對api的描述的單一方言。這是一件好事(我們中的一些人仍然記得“這個站點只在網景領航員（網景瀏覽器）中工作”)，最後，api的消費者通常不關心他們是如何描述的。如果這個機制是標準化的，更多的“東西”可以相互交流，那麼每個人都會贏。

  看到圍繞OAS的行業集會是令人滿意的，現在RAML API規範可以表示為OAS契約，我們可以從這些契約中獲得整個API生態系統的全部價值，為機器對機器的通訊提供一致規範，更重要的是，它可以驅動API的生命週期。

  我們已經做了很多公開的討論，並且有成千上萬的個人時間投入到這個專案中;在開始的時候設定正確的目標是贏得REST社群核心的關鍵，因此我們期待與MuleSoft的RAML團隊合作，在正在進行的OAS努力中利用他們的領域專業知識。

原文連結：