昨天，RAML 的創建者 MuleSoft 宣布他們已加入 Open API 計畫。OpenAPI 計畫由 SmartBear Software 創建，並以廣受歡迎的 Swagger 規格為基礎，是 Linux 基金會的專案，擁有超過 20 名成員，包括 Adobe、IBM、Google、Microsoft 和 Salesforce。
對於 API 產業的關注者來說，這明顯是 OpenAPI 規格 (OAS) 收斂的訊號。RAML 將繼續在 OAS 之上提供額外的建模功能，但最終的合約很可能將透過 OAS 進行。Apiary（現在是 Oracle 的一部分）於 2016 年加入 Open API 計畫，將 OAS 帶回他們以文件為重點的 Blueprint 格式。
Swagger (OAS) 如何成為標準？
回顧過去，最令人關注的問題是，在 2013 年至 2015 年之間的「偉大的 API 描述戰爭」中，OAS（透過 Swagger）如何以輕量級、社群為基礎的方式成為領先的格式？（而且這一切都在沒有正式的公司支持的情況下，直到 Swagger 在 2015 年初轉移到 SmartBear？）
其中有行銷、工具、(不可否認的) 絕佳名稱等等。但如果我退一步，忽略所有這些因素（這並不容易），而單單關注規格本身，就會清楚地看到 Swagger 贏得戰爭的原因，以及其他格式為何會向其靠攏。
Swagger 的開始只有少數幾個目標——涵蓋所有使用案例肯定不是其中之一。有了這個目標，Swagger 的創始人以三個簡單的目標建立了這個專案
- 易於人類閱讀。這表示規格必須簡潔、有條理且夠清楚，讓「一般」人能夠理解。
- 易於機器閱讀。這需要結構和「規則」，以便規格本身可以被解釋為由電腦「執行有用的操作」。
- 足夠詳盡以描述取用或產生 REST API 所需的一切。
雖然最初的 1.0 Swagger 規格有一些缺點，但它確實遵循了上述規則，因此我們能夠建構非常穩健且有價值的工具來利用它。
這與當時其他兩種領先的格式有何不同？
很簡單
- API Blueprint 是一種非常乾淨的文件格式。它是為人類設計的，並且僅限於 Markdown。後來開發了允許以不同格式撰寫的工具，但這明顯著重於文件而非描述。有什麼不同？這就像閱讀法律文件的摘要與閱讀文件本身。雖然對於文件來說很受歡迎，但機器可讀的結構、嚴格的綱要和「可操作的擴展」的概念似乎不太適合 Markdown。
- RAML 中的「ML」代表「建模語言」。這表示 RAML 的設計目標是能夠建模大量的 API，但這可能不是任何特定 API 或開發人員需要的。他們所需要的都是一種以明確的機器可讀方式描述合約的共同方式。
這對未來有什麼意義？
很多！但就像 1990 年代末期的瀏覽器大戰一樣，我相信我們看到 API 的單一描述方言正在收斂。這是一件好事（我們有些人還記得「此網站僅適用於 Netscape Navigator」的消息），因為最終，API 的使用者通常不關心它們是如何描述的。如果機制標準化，並且有更多「東西」可以溝通，那麼每個人都會贏。
看到產業團結在 OAS 周圍，以及現在 RAML API 規格可以表達為 OAS 合約，這令人感到滿意，我們可以從 API 生態系統中這些合約獲得完整價值，為機器對機器溝通提供共識，而且重要的是，推動 API 生命週期。
我們在專案中進行了許多公開辯論，並投入了數千小時的個人時間；事實證明，在開始時設定正確的目標是贏得 REST 社群信任的關鍵，因此我們期待與 MuleSoft 的 RAML 團隊合作，在持續的 OAS 工作中利用他們的專業知識。
[caption id="attachment_694" align="aligncenter" width="310"]
2013 年偉大的 API 格式戰爭期間，與 RAML 創建者 Uri Sarid、API Blueprint 創建者 Jacob Nestril 和 Swagger 創建者 Tony Tam 進行的眾多 IPA 資助的公開辯論之一[/caption]
已更新：此貼文已更新，以釐清一些事實要點並解決一些潛在的誤解。