什么是 API 優先？

許多公司最初構建 Web 或移動應用程序，然后作為附加項目開發 API，導致設計時未能充分構建和測試 API。這種方法的問題在于，它會導致人工 API 的設計過程不夠嚴謹。

相比之下，API 優先開發策略強調首先構建 API，再基于該 API 開發應用程序。這迫使團隊設計一個對開發人員友好的 API，確保其更真實且易于使用。API 優先開發關注開發人員的利益，從而節省大量工作，并為其他團隊提供良好的構建基礎。

為了簡單起見，可以想象在構建云原生應用程序時，代碼提交到存儲庫后，測試會自動運行，候選版本能在幾分鐘內上線。在這種理想環境下，多個團隊能夠順利合作，提供各自的服務。

然而，如果不進行有效的協調，可能會導致集成失敗的噩夢。API 優先方法通過將 API 視為核心開發工件，使團隊能夠在不干擾內部流程的情況下，專注于彼此的公共合同。

即使不打算將服務整合進更大生態系統，從 API 級別開始開發也會帶來顯著好處，值得投入時間。

為什么要 API 優先開發？

目前的開發過程不是并行的，而是同步的。

一旦需要開發新服務或新功能，研發團隊就會開始進行設計。完成后，后端團隊開始編寫原型（前端和問答等其他團隊正在等待）。原型完成后，可以準備 API 文檔并與不同團隊（問答、前端）共享。

當由于功能、錯誤、改進或增強而需要更改時，這個循環將再次開始，從而浪費寶貴的開發時間并縮短新服務的上市時間。

code first approach 如上圖所示，首先，后端團隊開始開發和實現新的 API。其次，將 API 提供給前端團隊和測試人員使用和測試。第三，前端團隊和測試人員正在構建 sdk、測試等與 API 交互。這就是同步開發。

api-first 開發將允許所有團隊并行開發，而無需等待一個團隊或另一個團隊發布更改。

api first approach 在上圖中，我們可以看到創建的第一個 API 是模擬的。其次，后端、前端和測試團隊都開始使用模擬的 API。一旦 API 準備就緒，所有團隊都可以切換到生產或暫存 API。這節省了大量的開發時間。

Restcase 為 API 提供模擬、調試、自動文檔和測試工具，并在所有設計和開發階段提供團隊通知和共享，使協作式 API 優先方法的工作變得更加高效。

構建服務 API 優先

如今，移動優先的概念越來越受到關注，指的是從項目一開始就圍繞可供移動設備使用的產品進行構建。同樣，API 優先意味著構建的是供客戶端應用程序和服務使用的 API。

云原生不僅僅是一系列規則或指南，而是一種哲學，某種程度上更是一種生活方式。云原生指南雖然不一定符合云所施加的特定物理要求，但對構建現代應用程序的人員和組織至關重要，這些應用程序需為未來云環境的變化做好準備。

每一個決策和代碼行都需圍繞 API 滿足應用程序的每個功能需求。即使是用戶界面，無論是 Web 還是移動，實際上也是 API 的消費者。

通過首先設計 API，可以在編寫代碼之前促進與利益相關者（內部團隊、客戶及其他使用 API 的團隊）的討論。這種協作有助于構建用戶故事、模擬 API 并生成文檔，以進一步明確服務的意圖和功能。

這些討論和測試可用來審查方向和計劃，而不需在支持特定 API 的管道上投入過多。

如今，有無數工具和標準支持 API 優先開發，API 規范使用類似 Markdown 的語法（如 API Blueprint 或 Swagger）。這些格式可用于生成文檔甚至 REST API 服務器模擬，在測試服務生態系統中非常寶貴。

因此，絕對沒有理由認為 API 優先是一條困難或不受支持的道路。這種模式適用于非云軟件開發，但特別適合云開發，因為它支持快速原型設計、服務生態系統和自動化部署測試。

這種模式是合同優先開發的延伸，開發人員首先專注于構建應用程序的邊緣或接縫。通過 CI 服務器不斷測試集成點，團隊可以獨立處理服務，并保持正常工作的合理保證。

API 優先將組織從瀑布式、精心設計的系統中解放出來，允許產品演變為有機的、自組織的生態系統，能夠不斷發展以應對新的和不可預見的需求。

概括

構建一個緊密耦合的整體系統會限制適應新需求或支持新消費者的能力。而采用 API 優先的心態，可以將所有應用程序視為支持服務，從而使系統自由增長，適應新的負載和需求，容納新消費者，而無需重建封閉系統。這種 API 優先的生活方式能夠帶來顯著的投資回報。

原文鏈接：An API-First Development Approach