API優先方法的完整指南 - ITNEXT

背景
從產品的想法出現在人們腦海中的那一刻起，到產品完成並推出的那一刻，需要採取數百（如果不是數千）的步驟；結果，儘管有出色的想法和商業計劃，許多團隊仍無法構建應用程式。因此，如果有一個設計、開發、釋出和營銷產品的指南，這對所有這些團隊來說都是一個巨大的幫助。此外，團隊可以從擴充套件他們的應用程式和加快完成產品的步伐中受益。許多引入的方法之一是API-First方法。然而，在我們深入研究 API-First 方法之前，讓我們首先建立一些關於先決條件概念的基礎知識。

回顧什麼是 API
大家可能都聽說過 API 與服務員的相似之處，但這次讓我們從技術上更深入地研究 API。首先，讓我們一起回顧一些核心概念，然後我們將開發 API 有用的原因。
API是Application Programming Interface的縮寫，是兩臺機器甚至兩個程式之間的連線。因此，您可以將 API 想象為兩個端點之間的中介軟體，用於傳輸資料並在給定時間使用給定資料呼叫某些功能。出於安全原因，API 也很重要。由於幾乎每個應用程式都有需要儲存在資料庫中的資料，因此讓使用者直接連線到資料庫來獲取、更新、建立和刪除是不安全的他們的資料手動。在這裡，API 從應用程式接收必要的資訊並將其傳送到伺服器，一旦伺服器為 API 提供響應，API 就會將響應返回給客戶端。回顧一下，以下是 API 的工作原理：

• 客戶端發起呼叫 API 的請求。請求中必須包含以下內容：請求 REST 動詞、URI（統一資源識別符號）、請求標頭，如果動詞需要正文，則還需要請求正文。
• API 與程式聯絡。收到請求後，API 將到達伺服器並與之連線。然後，伺服器開始處理資料並可能進行一些計算來為 API 準備正確的響應。
• 伺服器向 API 傳送響應。在處理並完成請求後，一旦伺服器準備好資料，它就會將其傳輸到 API（我們稱之為響應）。
• API 向客戶端傳送響應。一旦 API 從伺服器收集到響應，它將準備好使用HTTP協議將響應傳送到應用程式。

不同型別的 API
Web API 由 HTTP 協議提供支援。您可以在 Web API 中找到儲存（例如，本地儲存和會話儲存）之類的服務，或者您可能希望控制瀏覽器的通知。Web API 通常使用 JavaScript，儘管這不是必須的。如果您曾經是前端開發人員，那麼當您想查詢當前頁面的 URL ( window ) 或想要設定計時器以稍後執行某些操作 ( setTimeout ) 等時，您肯定已經越過了它們。最常用的 API 是Web API，它包括四種主要型別。

• 開放（公共）API：它們可供所有人使用。它可能需要註冊，但它們是公開的，供外部使用者使用。例如，您可以在此處檢視Google API 的完整列表。
• 內部 API：如果您有隻想在公司（或業務合作伙伴）內釋出的敏感資訊，那麼您正在檢視的是內部 API。
• 合作伙伴 API：它們與開放 API幾乎相同，但 您可以使用API 閘道器限制您的 API 對特定使用者的訪問。在軟體開發中，這種方法普遍用於控制對付費 API 和包含敏感資訊的 API 的訪問。
• 複合 API：如果您需要在一次呼叫中傳送多個請求，您可以使用這種 API。 這些 API 的好處之一是您可以將一個 API 的輸出用作另一個 API 的輸入。

不同型別的 API 協議
雖然 API 的主要職責是在兩個端點（機器或程式）之間建立安全可靠的連線，但這只是它的一般概念。我們需要實現我們的 API 來解決我們的問題並最佳化我們產品的效能。因此，程式設計師多年來引入了不同型別的 API，並且它們中的每一個都比另一個具有一些優勢。此外，還引入了不同的 API 架構和協議來指定我們想要建立的資料型別和規則。API 有三種主要協議：REST、SOAP和RPC。我們將學習它們中的每一個的基礎知識，然後我們將深入研究REST，因為我們想學習API-First 方法使用 REST 概念。
RPC（遠端程式呼叫）
該協議使用客戶端-伺服器模型在兩個程式之間建立通訊，而無需瞭解網路細節。RPC 的整個想法是我們想從另一臺計算機或機器呼叫我們伺服器中的一個函式。例如，假設我們有兩臺伺服器（伺服器 A 和伺服器 B），我們想從伺服器 B 呼叫伺服器 A 上的一個函式。當然，這些伺服器有可能不使用相同的程式語言，所以我們需要實現一些即使在不同語言中也可以呼叫的東西，這就是RPC派上用場的地方。
您可以在XML或JSON之間選擇資料型別格式。最流行的 RPC 框架是GRPC（G代表Google！），您可以在 JSON、Protobuf、Thrift 或 XML 之間選擇您的資料型別。

SOAP（簡單物件訪問協議）
SOAP是一種基於XML的無平臺應用程式通訊協議，用於傳送和接收在 2000 年代初期廣泛使用的訊息。它是一個具有以下結構的 XML 文件：

• SOAP 信封：它是每個 SOAP 訊息的包裝器，由兩個子元素組成：Header 和 Body。這部分負責指示 XML 文件是 SOAP。
• SOAP 標頭SOAP 標頭是 SOAP 信封的子項之一。與 Body 不同，Header 不是強制性的，它包含訊息的後設資料和與應用程式相關的資訊。它用於兩個端點之間更好的通訊。它允許您向分散的 SOAP 訊息新增功能，而無需通訊雙方事先達成一致。
• SOAP 正文每個 SOAP 訊息的重要部分是它的正文（這是強制性的）。它包含請求和響應資訊。
• SOAP 故障如果發生故障，SOAP 為我們提供了一種特殊的 Body，用於報告和處理錯誤，這是 SOAP 故障的責任。

REST（表徵狀態轉移）

Roy T. Fielding博士 論文介紹了REST概念，導致大量使用 API 在應用程式（客戶端）和伺服器之間建立可靠連線。此外， REST易於實現、易於理解並且在語言和框架中被廣泛接受。考慮到我們的大量系統都是基於客戶端-伺服器的，REST 表示類似於下圖：

我們有一個伺服器，其中包含應用程式所需的所有必要資源（例如載入頁面、媒體和應用程式正常執行所需的資料的所有檔案）。我們在應用程式（客戶端）中使用REST API訪問資源。我們用於在客戶端和伺服器之間建立連線的協議是HTTP。

REST API 請求和響應：
我們可以在 REST 環境中執行四個操作：建立、讀取、更新、刪除（AKA CRUD），我們為每個操作分配了一個或多個 REST 動詞（GET、POST、PUT、DELETE 等） . 為了操作伺服器中的資源，我們可以使用這些動詞，但首先，我們需要為它們中的每一個實現一個 API。

什麼是 API 優先方法？
每個應用程式最關鍵的部分是它的業務邏輯。業務邏輯是將所有其他元件聚集在一起的一件事，因此您可以擁有一個有意義的應用程式。API-First 方法將您的所有 API 視為一等公民，以類似於您的業務邏輯的方式使用它們。在這種方法中，在專案的文件和業務模型準備好之後，我們就可以開始設計 API。透過這種方式，我們可以防止與利益相關者溝通不暢而發生的問題。

與 API-First 不同的是Code-First方法，一旦定義了專案，開發人員就開始編寫程式碼。在專案初始化之初實現服務、元件和資源可能聽起來很有希望，因為您正在取得進展，但事實並非如此！由於重點是實現和編寫程式碼，而不是為您的專案設計和建立可靠的結構和體系結構，因此該專案可能不是客戶的願望。這將導致在實施過程中重構和重寫您的程式碼庫，這是任何團隊都不希望的。
API 優先方法的好處

開發軟體或應用程式幾乎總是一項集體活動。你需要成為一個團隊合作者才能在其中取得成功。為保證應用程式的開發過程順利進行，領導者應密切關注團隊成員並確保他們適當地一起工作。API-First 方法是團隊領導者在維護專案時可以考慮使用的方法之一。
由於我們首先設計 API，因此我們透過實現它們從一開始就應該採用的方式來降低重新實現應用程式的成本。這可以防止不必要的會議，這會消耗團隊的大量時間和精力。

另一方面，每個團隊成員都參與了專案的設計和架構。這很重要，因為它可以幫助他們所有人獲得寶貴的經驗並幫助他們在職業生涯中成長。
另一個重要的事情是並行工作的能力。假設我們要實現一個 Web 應用程式。一旦 API 的結構準備好，前端開發人員就可以開始實施應用程式的客戶端，另一方面，後端團隊正在實施其他 API。同時，整個團隊合作以獲得他們可以實現的最佳解決方案，以實現其他 API 的結構。

由於後端團隊和前端團隊同時工作，他們可以在實施過程中相互告知可能出現的問題，並節省大量時間。

API 優先方法的優勢
API 優先方法的必要性是什麼？
現在我們已經瞭解了什麼是 API-First 以及它的好處，我們需要確定我們的團隊是否有資格開始實施它。如今，許多大型公司都在轉向 API-First 方法。隨著公司規模的擴大，我們面臨著更多的麻煩，正如伊朗的一句古老 諺語所說：
更大的屋頂吸收更多的雪！

我們需要擔心的第一件事不是實現 API-First 的技術細節，而是為團隊成員和經理建立一種文化，以便對這種方法有很好的理解。讓每個人都在同一頁面上是這種方法的主要必要條件之一。建立這種文化不僅是專案經理的職責，團隊的每個成員都應該參與其中。

下一步將是為我們的通訊和文件實施基礎設施。一開始我們可能會遇到很多會議，如果我們沒有合適的會議媒介，事情會很快失控，以至於我們一開始都沒有意識到。收集所有必要的資訊並記錄它們以供將來使用需要適當的例程和協議。您無法想象在設計不佳的系統中事情會變得多快。

開始實施 API-First
好的！現在一切都已處理完畢，我們可以開始在我們的專案中實現 API-First 方法。

1、初次會議
儘管 API-First 方法減少了您花在會議上的時間，但它仍然需要團隊聚集在一起進行頭腦風暴，尤其是在專案開始時。所有團隊成員都需要了解利益相關者的確切需求和他們的期望。請記住，記錄所有會議至關重要（並且可能在每個人的許可下記錄它們）。

2、團隊成員介紹
如果您的團隊中有新成員或團隊成員不認識利益相關者，那麼所有團隊成員都必須相互認識。擁有健康的關係將提高團隊的績效。這一步的另一個重要好處是每個人都會知道每個人的確切職責，並且會減少官僚主義。

3、建立設計和開發的文化
正如我們之前所討論的，建立文化是 API-First 方法的先決條件之一。這也是實施它的關鍵部分。團隊需要有一套關於開發方法、專案架構和設計、編碼風格指南等的可靠規則。作為專案經理，您有責任確保您的每個團隊成員都瞭解這些規則。

4、標準化 API
您可以使用許多工具來標準化您的 API。但後端和前端團隊之間必須有共同的語言。請不要將此與文件混淆，因為我們在這裡討論的是

5、技術團隊之間的共同語言。
雖然它可能有助於醫生在實驗室報告中寫評論，但他們都可以從報告中收集必要的資訊。開發商也應該如此。它們之間應該有一種技術和通用語言，以便與一種技術語言直接互動。

6、自動化、測試和部署
應該有關於專案如何以及何時釋出新版本的具體規則。有很多工具可以用於語義版本控制。測試現在是您需要考慮的任何應用程式不可分割的一部分。

還有兩件事……
像許多軟體開發方法一樣，您需要注意兩個關鍵規則：

1. 沒有一種方法適用於所有人。每家公司都應該從一種方法中獲得靈感，並對其進行定製以更好地滿足他們的需求。關鍵的一點是，他們不應該過多地定製方法，以至於結果與基本方法完全不同。
2. 一個專案就像一個嬰兒。它需要不斷的照顧才能成長。有時似乎有一段時間沒有進展，但沒關係。這就是像敏捷這樣的方法可能派上用場的地方。