隨著產業成熟，勢必會出現標準，以實現更好的工程和使用方式。
自古以來都是如此。無論是羅馬運河的幾何複雜性、埃及金字塔的三角形對稱性，還是印度寺院的空間和諧，標準和規格都幫助工程師為永續工程設定了獨特的規則。
標準有助於提供共同的溝通和開發框架，並讓我們根據特定需求選擇正確的工具。
在 RESTful API 世界中，API 定義的標準是 OpenAPI 規格 (OAS)。
OAS 以原始的「Swagger 規格」為基礎，在 API 開發中獲得了巨大的吸引力，我們看到數以萬計的 API 開發人員和使用者採用它。
但為什麼是現在？為什麼當幾年前 REST 愛好者幾乎完全反對使用規格來定義 REST 時，世界突然開始接受 RESTful 架構的標準規格？
REST API 的新時代
API 不再局限於應用程式的後端。早在個人電腦出現之前，API 就已存在，將不同的邏輯單元連接在一起。
過去，API 並非供很多人使用。API 是資料驅動的，旨在解決少數幾個特殊的連線和通訊用例。文件極少（如果有的話），並且使用的規範直接採用核心資料庫中的術語，這意味著一小部分人以外的人無法理解它們。
毋庸置疑，過去的 API 並非供自助式使用。
以上內容不再適用於現代網路 API。我們正處於一個新時代，API 不僅讓企業能夠更快地建置和擴展，還透過整合和使用第三方服務來實現共同收益和成長，從而推動策略和業務目標。與它們的前身不同，新時代的 REST API 並非資料驅動，而是更以消費者為導向。
設計良好的 API 可以解決實際的消費者問題，這才是重點，我們在 Dropbox、Stripe 和 eBay 等公司的 API 中看到了這種關注。許多公司現在都需要基於 HTTP 標準的可重複使用介面，這些介面可以重複使用資料和功能，專為消費者需求和自助式服務而建置。
加入 OpenAPI 規格 (OAS)
OAS 對於 REST 來說就像 WSDL 對於 SOAP 一樣。它為設計師、開發人員、測試人員和開發營運人員提供了一個共同的框架來建置和維護 API。將規格視為一組用於建置和實作 REST API 的規則。OAS 與語言無關，並且可供人類和機器讀取，這允許人員和電腦發現和理解服務的功能，而無需存取原始程式碼、其他文件或檢查網路流量。
因此，我們知道 OAS 可以協助您建置以消費者為中心的 API，但是如何在開發生命週期中充分利用規格呢？
以 OpenAPI 驅動 API 開發
定義驅動的 API 開發主張在實作任何其他生命週期操作之前，先設計 API 的定義。這意味著，即使在您開始建置 API 的業務邏輯之前、在您針對任何錯誤或缺陷測試 API 之前或任何其他生命週期功能之前，您都將設計 API 的介面，詳細說明您的 API 端點將顯示的確切請求和回應。
以 OAS 驅動方法的好處
定義驅動的方法帶來了一些巨大的好處，這些好處直接關係到以消費者為導向的 API 開發方法。
- 更好的開發人員體驗 (DX)：DX 是開發人員在使用和整合您的軟體時可能體驗到的所有體驗的總和，無論是正面的還是負面的。在競爭激烈的 API 生態系統中，良好的 API 使用開發人員體驗至關重要。您實際上可以預先關注 API 消費者的需求。這讓您可以採用以開發人員為中心的方法，並確保在與時間和開發的其他方面競爭之前，以最佳方式滿足您的最終消費者的需求。
- 啟用獨立性：該方法減少了在您的 API 上工作的不同團隊（例如前端和後端團隊，或架構師、技術寫作人員和 QA）之間的依賴關係。這是因為 API 的定義讓各利害關係人了解 API 應該做什麼，以及它與他們的工作職能有何關聯。它充當 API 的預期服務及其功能之間的合約，並確保它們之間更容易溝通。
- 更快上市：由於消除了依賴關係，不同的團隊實際上可以更快更有效率地執行其功能。團隊之間的交接流程明顯更輕鬆，這使得您的 API 可以更快地發布。
總結
現代 API 不再符合傳統以資料為中心的世界觀。軟體和硬體應用程式都已連接，而 API 位於這場數位革命的中心。為了使這些應用程式連接起來，我們需要真正的開發人員了解您的 API 的作用，這就是為什麼以消費者為中心的 API 觀點正在迅速流行。
OpenAPI 規格可協助您實現解決潛在客戶需求的 API，同時透過定義驅動的方法確保良好的開發人員體驗。
您現在可以觀看此按需網路研討會，了解以定義驅動的方法進行 API 開發。在接下來的幾個月中，我將推出更多文章，詳細解釋 OAS 定義如何在不同的 API 生命週期功能（如 API 設計、文件、測試和監控）中提供協助。