只有在有創新支援的情況下，科技才能觸及大眾。以 iPad 為例。雖然平板電腦的概念在 2010 年 iPad 發布之前就已存在多年，但 Apple 能夠在 iPad 上取得成功，部分原因是當時 WiFi 連線的普及。

如果連線的普及能夠使平板電腦成為現實，那麼描述格式的普及就能使 API 在商業上取得成功。OpenAPI 規格 (OAS) 已成為全球 RESTful 介面的標準描述格式。OpenAPI 規格是針對您的 REST API 的人類友善、機器可讀的介面。OpenAPI 規格描述 API 的功能，包括 API 公開的資源及其相應的請求和回應。

此格式讓 API 的內部利害關係人和外部使用者之間更容易存取和協作。簡而言之，OpenAPI 規格改變了建構和交付 API 的方式。

OAS 由 Linux Foundation 底下的 OpenAPI Initiative (OAI) 管理。作為 Linux Foundation 底下的開放治理結構，OAI 致力於建立、發展和推廣廠商中立的描述格式。

我有機會在今年的 API Strategy & Practice Conference（APIStrat 2017）上與 OAI 技術指導委員會 (TSC) 成員 Darrel Miller 對話。Darrel 分享了有關 OAS 專案現況的寶貴見解，以及業界如何採用最新版本的規格 OAS 3.0。

OAS 3.0 的現況

OAS 3.0 是在今年稍早發布的嗎？到目前為止，您收到的回饋如何？

到目前為止，回饋非常正面！我們對結構進行了一些良好的清理和重組，以使規格更易於閱讀。很高興看到我們在 OAS 3.0 中所做的一些變更，使我們更接近 HTTP 的運作方式，並讓許多開發人員能夠充分發揮其功能。

我們確實收到許多人對 WebHooks 和連結功能感到興奮。連結功能是一個非常有趣的變數。我認為它可以做很多很酷的事情。許多人錯誤地認為我們試圖體現超媒體，而這總是一個與人們進行的有趣對話，特別是考慮到我本身在超媒體方面的背景。

OpenAPI 規格 3.0 正在滿足那些喜歡使用靜態設計原則來建構 API，並定義 API 中操作和資源之間關係的公司之真實需求。它絕對已成為基礎架構的關鍵部分。

我認為 OAS 3.0 也有可能大幅改善 API 的文件，因為突然之間，您現在可以描述 API 的流程。我認為情境是描述和撰寫 API 文件的好方法，而連結可協助我們走向流程之間文件自動化的實現之路。我很想看看人們會圍繞著它建立哪些工具。

我個人很想看到更豐富的 API 文件用例，以及資源之間更好的關係處理。

我的意思是，當您進入 API 時，我該如何使用它？我該從哪裡開始？有 150 個資源和一個長長的字母順序清單，您必須開始查看路徑結構，並決定其含義，並嘗試從中進行推論。但是，如果您可以實際告訴您的使用者：「那麼，這是您的起點，從這裡您可以去要求資訊。」

您並不需要遵循該路徑。您可以跳到這些端點，但至少對於了解 API 的組成方式來說，它是對 API 結構語義的重大補充。

採用是任何技術努力的重要組成部分。OAI 如何教育和宣傳 OAS 3.0？

我認為您不應該在工具支援尚未成熟時過早進行大規模的推廣，但到目前為止看到這樣的採用情況真是太好了。我們了解到，OAS 可以被廣泛採用的唯一方法是透過更多工具支援。我們在 GitHub 專案的實作頁面中列出了所有支援 OAS 3.0 的工具。看到此清單每天都在增加，真是令人興奮。

當涉及到圍繞 OAS 的工具時，我們看到從 Ruby 和 NodeJS 到 .NET 和 JavaScript 的不同技術都有很好的分佈。

為了進一步支援我們的行銷計畫，我們已與一家行銷和品牌公司簽約，以提高大眾對 OAS 的認知。我們也考慮過宣傳，但我認為現在還為時過早，因為我們仍在努力確保獲得所有正確的工具，來支援 OAS 必須提供的所有功能。

APIStrat 2017 是 OAI 贊助的第一個主要活動。您在本屆會議上注意到什麼？

顯然，今年的 APIStrat 更強調 OpenAPI。我希望這不僅僅是因為在過去 12 個月中，我們發布了新版本的規格，並且 API 領域的所有人終於針對將 OpenAPI 作為 REST 介面的標準描述格式達成了共識。我認為我們都知道擁有 API 描述的價值，並且我們終於可以停止辯論哪種是最好的格式。我們實際上可以開始將越來越多的工具投入到周圍的生態系統中。

規格和工具的發展

由於不同的組織在 OAI 中投入大量資金，這如何增強規格發展的過程？

它根本沒有顯著改變。OAI 的架構旨在確保社群中的每個聲音都能被聽到。當成員公司加入該組織時，他們基本上是在公開聲明他們支持 OAS，而不是在它的發展中具有影響力。OAI 的成員資格完全獨立於規格本身的建構技術方面。

任何與 API 有關的社群人士都可以盡其所能地做出貢獻。您不需要成為會員才能為規格做出貢獻，就像您不需要成為會員才能閱讀、使用和從規格中受益一樣。

讓業界公司加入 OAI 對於動能、在這個領域獲得知名度以及建立 OAS 的信譽非常重要。然而，從技術角度來看，它沒有任何直接的關聯。從技術角度來看，重要的是讓更多的人加入。我們將致力於嘗試讓更多核心人物加入指導委員會。已經有許多人為該專案做出了廣泛的貢獻，我們希望提名並邀請這些人加入指導委員會。這將使他們對規格的確切內容有更多發言權，並幫助我們接觸更多的社群成員，以獲得更多意見。

為了讓更多人可以貢獻，我們在完成 OAS 3.0 之後花了一些時間來進行一些整理，並使我們的治理事項井然有序。我們正在制定開發人員指南，以向想要貢獻的人說明我們推薦的流程類型。

由於存在大量的工具，規格的原始版本 Swagger 規格非常受歡迎。展望未來，OAI 是否有任何計劃與更多供應商合作？

我們一直盡力鼓勵更多人開發工具，而且 OAI 的成員也正在開發工具。我們對於 OAI 的角色與責任和工具之間有相當嚴格的區隔。我們僅負責規格的治理。我們不希望官方組織涉入開發自有工具的業務。所有的工具都是第三方開發的；我們僅負責制定規格。

到目前為止，我們還不需要說服人們開發工具，因為公司已經在有機地開發工具。其中很多只是對生態系統中既有工具的更新。這只是我們需要完成規格，人們需要時間吸收它並能夠展現轉移到 3.0 的價值。

在您網站上發表的部落格文章中，您提到您最初對 OAS 持懷疑態度。您是否曾想過最終會與 OAS 合作？

不，我從來沒有想過會加入 OAI。我曾在座談會上說過，這不是從技術角度來看架構模式的正確性問題，而是它對真實人們工作流程的影響。從我的部落格文章中，您會看到我過去和現在都是超媒體的支持者。

當您使用 OAS 設計靜態 API 時，您會獲得某些好處，例如能夠產生文件框架和產生客戶端，但也會失去一定的彈性，這會迫使您制定版本控制策略以便隨著時間推移進行演進。

這是靜態設計和動態設計之間的權衡，我想在某個時候我意識到，我更願意成為解決方案的一部分，以幫助絕大多數開發人員建立更好的 API，即使他們選擇的是版本控制路徑而不是演進性路徑。

絕大多數公司都採用較簡單的方法，並利用靜態 API 描述的優勢。我很高興能夠參與這個計畫，公司從中獲得了巨大的價值。任何我能夠在引導 OpenAPI 規範未來發展方面做的事情，以便我們可以避免某些陷阱，我都樂於參與其中。

您認為 OpenAPI 是否會發展到支援其他框架或架構（如 GraphQL）？

HTTP 的設計具有可擴展點，而其中一種表現形式是媒體類型。Webhooks 很棒，因為 webhooks 很自然地融入了 HTTP 模型。

GraphQL 定義了一組很自然可以成為媒體類型的東西。查詢的媒體類型、結構化回應的媒體類型等。它們有自己的類型系統。如果現有的類型系統無法滿足您的需求，這很棒。Web 之所以能如此成功，是因為它在請求、您在層次結構中描述的資源以及您傳送回去的酬載之間有非常好的關注點分離，這些都是完全獨立的。

回到 OAS 能做什麼，如果任何架構風格都是為了很好地融入 HTTP 而建立的，而不是試圖在 HTTP 之上分層，那麼它就適合 OAS。我喜歡創新，人們正在做事情。GraphQL 本可以很好地融入其中，並與我們現有的所有技術並駕齊驅。我真的希望他們能以一種更自然地融入 HTTP 生態系統的方式來建構它。

我認為唯一可以融入 OAS 的另一種主要風格是 RPC 類型的 API，您實際上是在請求主體中隧道傳輸操作。這對我們來說仍然是一個挑戰，因為我們使用路徑來識別操作。我一直在思考如何讓操作不透過路徑來識別。例如，在 OAS 3.0 中，我們有這個新的執行時間表達式，可以加以利用。現在，我不確定這會如何運作，因為這樣就會有一大堆具有相同執行時間表達式的操作。它可能有不同的操作 ID 來唯一識別這些操作，也許？但問題是，在這一點上，我們是否離 HTTP 的運作方式太遠了？

關於這裡有很多非常有趣的對話，特別是關於我們如何在不開始用不是每個人都覺得有價值的東西來汙染規格的情況下，擴大我們所能支援的範圍。如果您開始做那些相鄰的 RPC 類型的事情，它會讓人感覺有點噁心，儘管我很想找到一種方法來支援想要以多種方式設計 API 的人們。

所以您剛剛告訴我們，OAS 想要支援的任何新功能都需要符合 HTTP 的運作方式。這些功能的可用性也是考量因素嗎？

我的意思是，這對採用至關重要，對吧？我讚賞 Tony Tam（原始 Swagger Spec 的創建者）將很多這方面的內容納入了規格中。他總是會反對任何必須過度設計或對終端使用者來說似乎太複雜的東西。

我們現在有越來越多非全職開發人員開始設計和建立 API，因此擁有易於使用的描述格式變得至關重要。我實際上已經與 OpenAPI 聚會上的一些人（他們是業務分析師和產品經理，而不是經驗豐富的開發人員）進行過對話。他們可能對實作 API 沒有最好的想法，但他們了解 API 應該涵蓋的商業案例情境。

結語

我想在結束這次對話之前，了解您在 API 領域中未來最興奮的事情是什麼？

我想看看人們使用 OAS 3.0 來處理連結和文件的方式。API 文件可能變得非常困難，幾乎到了讓人痛苦的地步。我希望某位擁有比我更強的技術寫作技巧和更出色的 UI 知識的人，能夠利用我們使用 OAS 建構的東西，然後運用它，並建立基於情境的文件框架產生器。

產生的文件只能帶您到那一步，但基於情境的框架可以消除產生大量可消費資訊的單調感。這是我最感興趣的事情之一。

然後我們就可以在產生的內容之上添加額外的價值。這絕對是一個有趣的領域，我對未來感到非常興奮。

有興趣開始使用 OpenAPI 3.0 嗎？請查看我們的免費培訓：OpenAPI 3.0，以及它對 Swagger 未來的意義