本世紀初，Amazon、eBay 和 Salesforce 等公司推動了網(wǎng)絡(luò)應(yīng)用程序接口標準化的趨勢。由于開放式網(wǎng)絡(luò) API 的網(wǎng)絡(luò)不斷擴大，任何人都可以使用這些 API，因此應(yīng)用程序的開發(fā)和集成方式發(fā)生了徹底變革。
在此期間，Amazon 創(chuàng)始人 Jeff Bezos 給員工們寫了一份備忘錄，這就是著名的 “Bezos API Mandate”。據(jù)次級資料顯示，這份備忘錄包括兩項戰(zhàn)略要求，任何 IT 領(lǐng)導者在尋求開發(fā)團隊工作價值最大化時都應(yīng)考慮這兩項要求。第一，任何團隊開發(fā)的軟件之間的所有接口都應(yīng)通過 API 來實現(xiàn)；第二，團隊在編寫內(nèi)部 API 時，應(yīng)將其視為供公司外部人員使用。
這種方法在很大程度上解釋了 Amazon 是如何將其計算基礎(chǔ)設(shè)施外部化的：首先是 Merchant.com（該公司的電子商務(wù)即服務(wù)平臺，供零售商建立自己的在線商店），然后是Amazon網(wǎng)絡(luò)服務(wù)（Amazon Web Services），這是一種更廣泛的服務(wù)，此后就可以獨立運行了。
時間快進到 2023 年，IT 領(lǐng)導者在過去二十年中總結(jié)出了更多關(guān)于有效開發(fā)和使用 API 的經(jīng)驗。macH 聯(lián)盟是一個由近百家技術(shù)供應(yīng)商組成的全球聯(lián)盟，旨在促進 “開放和實現(xiàn)最佳的企業(yè)技術(shù)生態(tài)系統(tǒng)”，重點關(guān)注微服務(wù)和 API。
在此，MACH 聯(lián)盟成員和其他 IT 領(lǐng)導者提出了以下三條戒律，這些戒律應(yīng)成為任何 API 戰(zhàn)略的基礎(chǔ)。這些原則不僅能確保軟件系統(tǒng)良好地協(xié)同工作，還能確保團隊協(xié)同工作，為企業(yè)的整體軟件開發(fā)戰(zhàn)略服務(wù)。畢竟，就像應(yīng)用程序接口一樣，當一個團隊為其他團隊提供服務(wù)時，承諾必須明確，邊界必須得到尊重。
01｜采用 API 優(yōu)先的方法
將 API 戰(zhàn)略發(fā)揮到極致的最有效方法就是采用所謂的“API 優(yōu)先”方法，即從一開始就將 API 作為軟件開發(fā)戰(zhàn)略的構(gòu)建模塊予以優(yōu)先考慮。
API 優(yōu)先型組織更注重接口而非集成。在編寫任何其他代碼之前，他們首先定義 API，包括其執(zhí)行的服務(wù)、接受的輸入和產(chǎn)生的輸出。這樣，他們就不會集成各種軟件組件來構(gòu)建單體應(yīng)用程序，而是使用組件化的服務(wù)，通過應(yīng)用程序接口提供給生態(tài)系統(tǒng)。Valtech 公司全球技術(shù)高級副總裁、MACH 聯(lián)盟總裁 Casper Rasmussen 說：“不采用 API 優(yōu)先方法的組織在設(shè)計 API 之前先開發(fā)軟件，這限制了 API 的實用性。”
Rasmussen 說：“API 優(yōu)先是指設(shè)計通用的接口，而不是針對特定的用例。如果你在現(xiàn)有的傳統(tǒng)軟件上安裝了 API，那么你就不是 API 優(yōu)先，至少在歷史上不是。傳統(tǒng)軟件帶有關(guān)于它做什么、對誰做以及在什么用例中做的假設(shè)。應(yīng)用程序接口優(yōu)先的通用性要強得多。舉例來說，假設(shè)消費者是網(wǎng)絡(luò)客戶端的 API 策略。它使用 html 進行通信，因此很難在其他環(huán)境中使用。”
API 優(yōu)先的方法使企業(yè)能夠充分利用微服務(wù)架構(gòu)，這是 SOA 的一種變體，在這種架構(gòu)中，應(yīng)用程序的結(jié)構(gòu)是松散耦合服務(wù)的集合。The Lego Group 就是一家采用 API 優(yōu)先方法的公司，因為這一概念模仿了 Legos 產(chǎn)品系列，積木上的標準接口使用戶能夠拼湊出一個更大的整體。
Lego Group 市場營銷和渠道技術(shù)副總裁 Niall Edwards 說：“我們的戰(zhàn)略重點是構(gòu)建松散耦合的系統(tǒng)，并由我們的產(chǎn)品團隊提供支持，他們構(gòu)建并運行 API 來公開他們的服務(wù)。多年來，我們的 Lego.com 技術(shù)平臺一直完全基于微服務(wù)和 API，現(xiàn)在我們正在所有技術(shù)領(lǐng)域推廣這種方法。現(xiàn)在，我們正在將這種方法推廣到更加單一的企業(yè)系統(tǒng)中。”
Lego Group 提供了一個完美的例子，說明 API 優(yōu)先的方法如何偏愛微服務(wù)，而不是更大、更復雜的功能。新的 API 應(yīng)能提供狹義的服務(wù)，可供各種應(yīng)用程序使用。舊系統(tǒng)可以通過 API 進行改造，使應(yīng)用程序能夠像使用新開發(fā)的服務(wù)一樣使用傳統(tǒng)服務(wù)。
隨著傳統(tǒng)技術(shù)投資的更新?lián)Q代，CIO 們最好確保只有在新供應(yīng)商提供微服務(wù)并符合 API 優(yōu)先原則的情況下，才能將其引入。
02 ｜制定并執(zhí)行 API 政策
為確保內(nèi)部和外部不同團隊開發(fā)的軟件組件之間的松耦合和高度一致性，有必要制定共同的 API 政策。
該政策應(yīng)說明某些服務(wù)由 IT 部門集中執(zhí)行，即使大多數(shù) API 工作是由不同的開發(fā)團隊獨立完成的。例如，為確保一致性，應(yīng)集中管理訪問控制，所有應(yīng)用程序接口都應(yīng)使用一種識別和驗證方案。數(shù)據(jù)格式也應(yīng)集中管理，以確保統(tǒng)一性。最后，服務(wù)水平協(xié)議（SLA）應(yīng)由 IT 部門定義和控制。例如，你可以規(guī)定，對于任何面向客戶的服務(wù)，應(yīng)用程序接口都應(yīng)在 50 毫秒內(nèi)做出響應(yīng)。
Edwards 說：“如果不明確誰負責什么，那么就會出現(xiàn)混亂，沒有人知道真相的來源。企業(yè)數(shù)據(jù)模型必須明確指出誰對哪些數(shù)據(jù)負責。數(shù)據(jù)的用戶需要知道，他們可以緩存和使用這些數(shù)據(jù)，但絕不能更改它們。對數(shù)據(jù)的更改只能發(fā)生在源頭，而且這些更改應(yīng)該是可發(fā)現(xiàn)的，并向所有消費者公開。”
API 需要得到微服務(wù)的支持才能發(fā)揮最大功效。CIO 應(yīng)以此為前提定義 API，然后在內(nèi)部構(gòu)建服務(wù)，或選擇提供符合這種方法的服務(wù)的供應(yīng)商。
身為 Commercetools 公司首席戰(zhàn)略官、四本關(guān)于 API 和微服務(wù)的書籍的作者 Kelly Goetsch 說：“API 應(yīng)該是可獨立調(diào)用的、無狀態(tài)的、可怠用的。這意味著應(yīng)用程序可以使用一個應(yīng)用程序接口，而無需先調(diào)用另一個，并且服務(wù)的內(nèi)部值不會發(fā)生變化，不會導致每次調(diào)用都產(chǎn)生不同的結(jié)果。例如，您可以多次調(diào)用應(yīng)用程序接口來添加到購物車，如果它是等冪的，那么每次調(diào)用時都會以相同的方式運行。”
Rasmussen 說：“最后，該策略應(yīng)確保不區(qū)分內(nèi)部 API 和外部 API。Bezos API Mandate 的精妙之處在于，API 默認需要外部化。如果你看看 AWS，它最初只是一個內(nèi)部項目，他們只是改變了公司內(nèi)部已經(jīng)在使用的 API 的訪問權(quán)限，就將其提供給了外部世界。”
一旦制定了 API 政策，關(guān)鍵是要確保所有團隊都能遵守。面對如此之多的移動部件、連接和傳輸中的數(shù)據(jù)，這是任何 IT 領(lǐng)導者都不應(yīng)忽視的一個重要方面。
03 ｜建立并維護 API 目錄
要實現(xiàn) API 愿景，可能需要提供如此廣泛的服務(wù)，因此還必須對貴組織正在創(chuàng)建的 API 以及貴組織可能依賴第三方提供的 API 進行索引。
Goetsch 說：“CIO 應(yīng)制定 API 目錄和管理該目錄的策略。目錄應(yīng)定義 API，并包含企業(yè)需要的所有功能。然后，你就可以決定是構(gòu)建還是購買提供這些服務(wù)的軟件。”
Goetsch 指出，雖然目錄應(yīng)集中維護，但實施的責任應(yīng)留給各個團隊或外部供應(yīng)商。但開發(fā)服務(wù)的人員必須遵守目錄中的規(guī)定。
他說：“實施應(yīng)用程序接口的團隊可以選擇他們的數(shù)據(jù)庫和其他很多東西。但如果他們搞砸了，就要追究他們的責任。你可以非常快速、輕松地判斷一個團隊的管理是否正確。如果應(yīng)用程序接口出現(xiàn)問題，你就知道出了問題。”
中央目錄應(yīng)該有完善的文檔記錄，并配有發(fā)現(xiàn)工具，使內(nèi)部和外部用戶能夠根據(jù)需求描述或一組關(guān)鍵字找到應(yīng)用程序接口。Edwards 認為：“Lego Group 在集中式可發(fā)現(xiàn)性工具方面進行了投資，以幫助開發(fā)人員找到彼此的 API，并利用它們組成更大的產(chǎn)品，就像人們使用樂高積木一樣。”
通過遵守這三條戒律并借鑒多年的經(jīng)驗，IT 領(lǐng)導者可以建立一個框架，確保每項服務(wù)都有清晰的路徑。消費者可以信賴一個可靠的界面，而生產(chǎn)者則可以獲得構(gòu)建服務(wù)所需的自由。每一方都可以在自己的時間內(nèi)進行創(chuàng)新。
來源：www.cio.com
