微服務逐漸被IT從業者所接受。但是伴隨著微服務的興起，人們逐漸認識到微服務管理的重要性與難度。API技術出現的時間比較長，對於API的管理經驗相對比較成熟。其中的很多經驗可以借鑑

在雲技術的推動下，越來越多的企業使用微服務來提供可以對市場快速反應的服務。但是伴隨著微服務的興起，人們逐漸認識到微服務管理的重要性與難度。SOA對於服務的管理經驗被大量的借鑑於微服務的管理。但是另外一個領域的管理理論與方法，同樣對微服務的管理有指導意義。這就是API的管理。下面討論一些API管理的核心元素，從而幫助我們的微服務管理。

API管理是指，在一個在安全的、可伸縮的環境中，開發、釋出和監控應用程式程式設計介面(API)的過程。下面對API管理的幾個方面做以介紹

1.      API規劃

理解為什麼要構建一個API是最基本的要求，瞭解您的API應該訪問哪些資料或者呼叫那些方法，以及您的使用者將如何使用它。許多公司都在開發API，認為資料易於訪問，使用者就會喜歡它，但這絕不是最好的理由。你到底在做什麼，為什麼，誰是你的API使用者？他們是你的客戶、第三方服務，還是開發者。API規劃時我們需要考慮這些問題

一旦您理解了為什麼要構建API，就需要列出您的API需要做什麼，或者建立User Story。在這個關鍵時刻，你不應該關注諸如GET、POST、PUT、DELETE之類的東西，這是具體的實現。你需要關注的使用者的需求，比如您需要能夠建立使用者、編輯使用者、更改密碼、重置密碼、檢視配置檔案。或者，在電子郵件系統中，可以建立電子郵件、閱讀電子郵件、建立草稿、傳送草稿、移動到資料夾、刪除、獲取聯絡人等等。

下面的工作是使用什麼型別的API，現在流行的是REST。但你的API不必是REST的，它也可以是JSON-RPC，甚至是SOAP……這取決於您的客戶需要什麼。如果您的所有客戶都使用依賴於SOAP庫的遺留系統，那麼在這種情況下，為他們構建一個SOAP API可能會更有意義。如果您是為了簡化系統而建立API，那麼JSON-RPC不會是一個好的選擇。決定因素是哪種型別的API滿足了客戶的需求。

不要只是侷限於為今天的產品或軟體規劃設計API。與設計應用程式一樣，保持API的標準化和可擴充套件也是非常重要的。我們可能很容易通過快速修復來滿足客戶的某一個需求，但是這樣的Quick Fix是否可以持續？是否可以持續滿足客戶？這都是需要仔細考慮的。

2.      API Agile

一旦您瞭解了您的API需要做什麼才能滿足需求，那麼下一步就是要確保它儘可能的靈活和可擴充套件。採用具有普遍意義的API開發最佳實踐，並將之用於工作中，這不僅意味著您的API對其他開發人員來說是熟悉的，而且還可以確保，在將來可以擴充套件和構建它。以下是一些最佳實踐，幫助提高API的敏捷性:

1）  使用名詞定義資源

如果您正在構建一個REST API，請確保您使用的是名詞而不是動詞。動詞在JSON-RPC中使用得更多. 通過使用名詞，REST可以充分利用HTTP自己的動詞(例如GET、POST、PUT等)，您可以擁有鬆散耦合的資源，可以完成多個任務，並在任何時候新增新的操作。

2）  使用CRUD

CRUD代表建立、讀取、更新和刪除。但是更簡單地說，在RESTful API中，CRUD是使用HTTP動作動詞的標準用法。這意味著，如果你想建立一個新的記錄，你應該使用“POST”。如果你想讀一份記錄，你應該使用“GET”。用“PUT”或“Update”更新一個記錄。然後刪除一個記錄，使用“Delete”。

3）  使用JSON(如果可能的話)

JSON可以實現快速序列化和反序列化物件。JSON為訪問資料提供了一種緊湊的格式，簡化了所需的資料傳輸，同時還提供了比XML更廣泛的語言支援。這些優勢使它成為許多開發人員選擇的格式，特別是在客戶需要的編碼為XML時，我強烈建議將JSON作為一種選擇，因為序列化是相當快速和無痛的。

4）  充分利用content –type header

為了真正讓你的API保持靈活和可擴充套件性，同樣重要的是，不僅要考慮現在的主流格式，而且還要為將來的格式保留餘地。因此，重要的是您的API不限制只使用一種格式。充分利用Content-Type header，你可以知道使用者的資料型別，這樣就可以返回同樣的資料型別。這樣的設計可以使你的API更加的靈活。

3.      API 的應答

確保API的可伸縮性和永續性是至關重要的，但同樣重要的是確保開發人員能夠理解您的API，並相信它能夠響應適當的頭程式碼和錯誤訊息。

使用合適的應答程式碼是API開發、設計的良好開始。通過使用正確的狀態程式碼，開發人員可以快速檢視應用程式的情況，並對錯誤進行“快速檢查”，而不必依賴於正文的響應。

在出現故障時，確保開發人員理解呼叫失敗的原因也很重要。這對於您的API的初始整合尤其重要(請記住，您的API越容易整合，人們就越有可能使用它)。良好的習慣是API可以提供良好的錯誤資訊。這意味著告訴開發人員發生了什麼，為什麼會發生，最重要的是如何修復它。您應該避免使用通用的或非描述性的錯誤訊息

4.      API 安全

API的隱藏危險是它可以暴露應用程式中的漏洞。API的故障或者是惡意的濫用都可以使您的伺服器宕機，從而為您和您的客戶造成停機。

通過向API使用者提供獨特的API Token或API Key，您可以準確地知道誰在呼叫API。除可以立即刪除的潛在惡意使用者，您還可以根據個人需求為使用者設定許可權和定義特殊的SLA。

API限制速率也成為可能。通過限制API並設定不同的SLA層，您可以幫助防止濫用。這意味著您的API能夠為所有使用者最優地操作，而不是因為一個惡性無限迴圈，讓所有使用者都崩潰。

除此之外，還應該警惕其他危險的威脅，如惡意IP、DDoS、內容威脅(如JSON或XML)等。

API也應該被設計成充分利用使用者自己現有的驗證系統，比如OAuth2，以幫助保護你使用者的敏感資料。