本世紀初，Amazon、eBay 和 Salesforce 等公司推動了網絡應用程序接口標準化的趨勢。由于開放式網絡 API 的網絡不斷擴大，任何人都可以使用這些 API，因此應用程序的開發和集成方式發生了徹底變革。

在此期間，Amazon 創始人 Jeff Bezos 給員工們寫了一份備忘錄，這就是著名的 “Bezos API Mandate”。據次級資料顯示，這份備忘錄包括兩項戰略要求，任何 IT 領導者在尋求開發團隊工作價值最大化時都應考慮這兩項要求。第一，任何團隊開發的軟件之間的所有接口都應通過 API 來實現；第二，團隊在編寫內部 API 時，應將其視為供公司外部人員使用。

這種方法在很大程度上解釋了 Amazon 是如何將其計算基礎設施外部化的：首先是 Merchant.com（該公司的電子商務即服務平臺，供零售商建立自己的在線商店），然后是Amazon網絡服務（Amazon Web Services），這是一種更廣泛的服務，此后就可以獨立運行了。

時間快進到 2023 年，IT 領導者在過去二十年中總結出了更多關于有效開發和使用 API 的經驗。MACH 聯盟是一個由近百家技術供應商組成的全球聯盟，旨在促進 “開放和實現最佳的企業技術生態系統”，重點關注微服務和 API。

在此，MACH 聯盟成員和其他 IT 領導者提出了以下三條戒律，這些戒律應成為任何 API 戰略的基礎。這些原則不僅能確保軟件系統良好地協同工作，還能確保團隊協同工作，為企業的整體軟件開發戰略服務。畢竟，就像應用程序接口一樣，當一個團隊為其他團隊提供服務時，承諾必須明確，邊界必須得到尊重。

01｜采用 API 優先的方法

將 API 戰略發揮到極致的最有效方法就是采用所謂的“API 優先”方法，即從一開始就將 API 作為軟件開發戰略的構建模塊予以優先考慮。

API 優先型組織更注重接口而非集成。在編寫任何其他代碼之前，他們首先定義 API，包括其執行的服務、接受的輸入和產生的輸出。這樣，他們就不會集成各種軟件組件來構建單體應用程序，而是使用組件化的服務，通過應用程序接口提供給生態系統。Valtech 公司全球技術高級副總裁、MACH 聯盟總裁 Casper Rasmussen 說：“不采用 API 優先方法的組織在設計 API 之前先開發軟件，這限制了 API 的實用性。”

Rasmussen 說：“API 優先是指設計通用的接口，而不是針對特定的用例。如果你在現有的傳統軟件上安裝了 API，那么你就不是 API 優先，至少在歷史上不是。傳統軟件帶有關于它做什么、對誰做以及在什么用例中做的假設。應用程序接口優先的通用性要強得多。舉例來說，假設消費者是網絡客戶端的 API 策略。它使用 HTML 進行通信，因此很難在其他環境中使用。”

API 優先的方法使企業能夠充分利用微服務架構，這是 SOA 的一種變體，在這種架構中，應用程序的結構是松散耦合服務的集合。The Lego Group 就是一家采用 API 優先方法的公司，因為這一概念模仿了 Legos 產品系列，積木上的標準接口使用戶能夠拼湊出一個更大的整體。

Lego Group 市場營銷和渠道技術副總裁 Niall Edwards 說：“我們的戰略重點是構建松散耦合的系統，并由我們的產品團隊提供支持，他們構建并運行 API 來公開他們的服務。多年來，我們的 Lego.com 技術平臺一直完全基于微服務和 API，現在我們正在所有技術領域推廣這種方法。現在，我們正在將這種方法推廣到更加單一的企業系統中。”

Lego Group 提供了一個完美的例子，說明 API 優先的方法如何偏愛微服務，而不是更大、更復雜的功能。新的 API 應能提供狹義的服務，可供各種應用程序使用。舊系統可以通過 API 進行改造，使應用程序能夠像使用新開發的服務一樣使用傳統服務。

隨著傳統技術投資的更新換代，CIO 們最好確保只有在新供應商提供微服務并符合 API 優先原則的情況下，才能將其引入。

02 ｜制定并執行 API 政策

為確保內部和外部不同團隊開發的軟件組件之間的松耦合和高度一致性，有必要制定共同的 API 政策。

該政策應說明某些服務由 IT 部門集中執行，即使大多數 API 工作是由不同的開發團隊獨立完成的。例如，為確保一致性，應集中管理訪問控制，所有應用程序接口都應使用一種識別和驗證方案。數據格式也應集中管理，以確保統一性。最后，服務水平協議（SLA）應由 IT 部門定義和控制。例如，你可以規定，對于任何面向客戶的服務，應用程序接口都應在 50 毫秒內做出響應。

Edwards 說：“如果不明確誰負責什么，那么就會出現混亂，沒有人知道真相的來源。企業數據模型必須明確指出誰對哪些數據負責。數據的用戶需要知道，他們可以緩存和使用這些數據，但絕不能更改它們。對數據的更改只能發生在源頭，而且這些更改應該是可發現的，并向所有消費者公開。”

API 需要得到微服務的支持才能發揮最大功效。CIO 應以此為前提定義 API，然后在內部構建服務，或選擇提供符合這種方法的服務的供應商。

身為 Commercetools 公司首席戰略官、四本關于 API 和微服務的書籍的作者 Kelly Goetsch 說：“API 應該是可獨立調用的、無狀態的、可怠用的。這意味著應用程序可以使用一個應用程序接口，而無需先調用另一個，并且服務的內部值不會發生變化，不會導致每次調用都產生不同的結果。例如，您可以多次調用應用程序接口來添加到購物車，如果它是等冪的，那么每次調用時都會以相同的方式運行。”

Rasmussen 說：“最后，該策略應確保不區分內部 API 和外部 API。Bezos API Mandate 的精妙之處在于，API 默認需要外部化。如果你看看 AWS，它最初只是一個內部項目，他們只是改變了公司內部已經在使用的 API 的訪問權限，就將其提供給了外部世界。”

一旦制定了 API 政策，關鍵是要確保所有團隊都能遵守。面對如此之多的移動部件、連接和傳輸中的數據，這是任何 IT 領導者都不應忽視的一個重要方面。

03 ｜建立并維護 API 目錄

要實現 API 愿景，可能需要提供如此廣泛的服務，因此還必須對貴組織正在創建的 API 以及貴組織可能依賴第三方提供的 API 進行索引。

Goetsch 說：“CIO 應制定 API 目錄和管理該目錄的策略。目錄應定義 API，并包含企業需要的所有功能。然后，你就可以決定是構建還是購買提供這些服務的軟件。”

Goetsch 指出，雖然目錄應集中維護，但實施的責任應留給各個團隊或外部供應商。但開發服務的人員必須遵守目錄中的規定。

他說：“實施應用程序接口的團隊可以選擇他們的數據庫和其他很多東西。但如果他們搞砸了，就要追究他們的責任。你可以非常快速、輕松地判斷一個團隊的管理是否正確。如果應用程序接口出現問題，你就知道出了問題。”

中央目錄應該有完善的文檔記錄，并配有發現工具，使內部和外部用戶能夠根據需求描述或一組關鍵字找到應用程序接口。Edwards 認為：“Lego Group 在集中式可發現性工具方面進行了投資，以幫助開發人員找到彼此的 API，并利用它們組成更大的產品，就像人們使用樂高積木一樣。”

通過遵守這三條戒律并借鑒多年的經驗，IT 領導者可以建立一個框架，確保每項服務都有清晰的路徑。消費者可以信賴一個可靠的界面，而生產者則可以獲得構建服務所需的自由。每一方都可以在自己的時間內進行創新。

來源：www.cio.com