本世紀(jì)初，Amazon、eBay和Salesforce等公司推動(dòng)了網(wǎng)絡(luò)應(yīng)用程序接口標(biāo)準(zhǔn)化的趨勢(shì)。由于開放式網(wǎng)絡(luò)API的網(wǎng)絡(luò)不斷擴(kuò)大，任何人都可以使用這些API，因此應(yīng)用程序的開發(fā)和集成方式發(fā)生了徹底變革。

在此期間，Amazon創(chuàng)始人Jeff Bezos給員工們寫了一份備忘錄，這就是著名的“Bezos API Mandate”。據(jù)次級(jí)資料顯示，這份備忘錄包括兩項(xiàng)戰(zhàn)略要求，任何IT領(lǐng)導(dǎo)者在尋求開發(fā)團(tuán)隊(duì)工作價(jià)值最大化時(shí)都應(yīng)考慮這兩項(xiàng)要求。第一，任何團(tuán)隊(duì)開發(fā)的軟件之間的所有接口都應(yīng)通過API來實(shí)現(xiàn)；第二，團(tuán)隊(duì)在編寫內(nèi)部API時(shí)，應(yīng)將其視為供公司外部人員使用。

這種方法在很大程度上解釋了Amazon是如何將其計(jì)算基礎(chǔ)設(shè)施外部化的：首先是Merchant（該公司的電子商務(wù)即服務(wù)平臺(tái)，供零售商建立自己的在線商店），然后是Amazon網(wǎng)絡(luò)服務(wù)（Amazon Web Services），這是一種更廣泛的服務(wù)，此后就可以獨(dú)立運(yùn)行了。

時(shí)間快進(jìn)到2023年，IT領(lǐng)導(dǎo)者在過去二十年中總結(jié)出了更多關(guān)于有效開發(fā)和使用 API 的經(jīng)驗(yàn)。MACH聯(lián)盟是一個(gè)由近百家技術(shù)供應(yīng)商組成的全球聯(lián)盟，旨在促進(jìn) “開放和實(shí)現(xiàn)最佳的企業(yè)技術(shù)生態(tài)系統(tǒng)”，重點(diǎn)關(guān)注微服務(wù)和API。

在此，MACH 聯(lián)盟成員和其他IT領(lǐng)導(dǎo)者提出了以下三條戒律，這些戒律應(yīng)成為任何API戰(zhàn)略的基礎(chǔ)。這些原則不僅能確保軟件系統(tǒng)良好地協(xié)同工作，還能確保團(tuán)隊(duì)協(xié)同工作，為企業(yè)的整體軟件開發(fā)戰(zhàn)略服務(wù)。畢竟，就像應(yīng)用程序接口一樣，當(dāng)一個(gè)團(tuán)隊(duì)為其他團(tuán)隊(duì)提供服務(wù)時(shí)，承諾必須明確，邊界必須得到尊重。

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)生的輸出。這樣，他們就不會(huì)集成各種軟件組件來構(gòu)建單體應(yīng)用程序，而是使用組件化的服務(wù)，通過應(yīng)用程序接口提供給生態(tài)系統(tǒng)。Valtech 公司全球技術(shù)高級(jí)副總裁、MACH 聯(lián)盟總裁 Casper Rasmussen 說：“不采用 API 優(yōu)先方法的組織在設(shè)計(jì) API 之前先開發(fā)軟件，這限制了 API 的實(shí)用性。”

Rasmussen 說：“API 優(yōu)先是指設(shè)計(jì)通用的接口，而不是針對(duì)特定的用例。如果你在現(xiàn)有的傳統(tǒng)軟件上安裝了 API，那么你就不是 API 優(yōu)先，至少在歷史上不是。傳統(tǒng)軟件帶有關(guān)于它做什么、對(duì)誰做以及在什么用例中做的假設(shè)。應(yīng)用程序接口優(yōu)先的通用性要強(qiáng)得多。舉例來說，假設(shè)消費(fèi)者是網(wǎng)絡(luò)客戶端的 API 策略。它使用 HTML 進(jìn)行通信，因此很難在其他環(huán)境中使用。”

API 優(yōu)先的方法使企業(yè)能夠充分利用微服務(wù)架構(gòu)，這是 SOA 的一種變體，在這種架構(gòu)中，應(yīng)用程序的結(jié)構(gòu)是松散耦合服務(wù)的集合。The Lego Group 就是一家采用 API 優(yōu)先方法的公司，因?yàn)檫@一概念模仿了 Legos 產(chǎn)品系列，積木上的標(biāo)準(zhǔn)接口使用戶能夠拼湊出一個(gè)更大的整體。

Lego Group 市場(chǎng)營銷和渠道技術(shù)副總裁 Niall Edwards 說：“我們的戰(zhàn)略重點(diǎn)是構(gòu)建松散耦合的系統(tǒng)，并由我們的產(chǎn)品團(tuán)隊(duì)提供支持，他們構(gòu)建并運(yùn)行 API 來公開他們的服務(wù)。多年來，我們的 Lego.com 技術(shù)平臺(tái)一直完全基于微服務(wù)和 API，現(xiàn)在我們正在所有技術(shù)領(lǐng)域推廣這種方法?，F(xiàn)在，我們正在將這種方法推廣到更加單一的企業(yè)系統(tǒng)中。”

Lego Group 提供了一個(gè)完美的例子，說明 API 優(yōu)先的方法如何偏愛微服務(wù)，而不是更大、更復(fù)雜的功能。新的 API 應(yīng)能提供狹義的服務(wù)，可供各種應(yīng)用程序使用。舊系統(tǒng)可以通過 API 進(jìn)行改造，使應(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)部和外部不同團(tuán)隊(duì)開發(fā)的軟件組件之間的松耦合和高度一致性，有必要制定共同的 API 政策。

該政策應(yīng)說明某些服務(wù)由 IT 部門集中執(zhí)行，即使大多數(shù) API 工作是由不同的開發(fā)團(tuán)隊(duì)獨(dú)立完成的。例如，為確保一致性，應(yīng)集中管理訪問控制，所有應(yīng)用程序接口都應(yīng)使用一種識(shí)別和驗(yàn)證方案。數(shù)據(jù)格式也應(yīng)集中管理，以確保統(tǒng)一性。最后，服務(wù)水平協(xié)議（SLA）應(yīng)由 IT 部門定義和控制。例如，你可以規(guī)定，對(duì)于任何面向客戶的服務(wù)，應(yīng)用程序接口都應(yīng)在 50 毫秒內(nèi)做出響應(yīng)。

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

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)該是可獨(dú)立調(diào)用的、無狀態(tài)的、可怠用的。這意味著應(yīng)用程序可以使用一個(gè)應(yīng)用程序接口，而無需先調(diào)用另一個(gè)，并且服務(wù)的內(nèi)部值不會(huì)發(fā)生變化，不會(huì)導(dǎo)致每次調(diào)用都產(chǎn)生不同的結(jié)果。例如，您可以多次調(diào)用應(yīng)用程序接口來添加到購物車，如果它是等冪的，那么每次調(diào)用時(shí)都會(huì)以相同的方式運(yùn)行。”

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

一旦制定了 API 政策，關(guān)鍵是要確保所有團(tuán)隊(duì)都能遵守。面對(duì)如此之多的移動(dòng)部件、連接和傳輸中的數(shù)據(jù)，這是任何 IT 領(lǐng)導(dǎo)者都不應(yīng)忽視的一個(gè)重要方面。

03｜建立并維護(hù) API目錄

要實(shí)現(xiàn) API 愿景，可能需要提供如此廣泛的服務(wù)，因此還必須對(duì)貴組織正在創(chuàng)建的 API 以及貴組織可能依賴第三方提供的 API 進(jìn)行索引。

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

Goetsch 指出，雖然目錄應(yīng)集中維護(hù)，但實(shí)施的責(zé)任應(yīng)留給各個(gè)團(tuán)隊(duì)或外部供應(yīng)商。但開發(fā)服務(wù)的人員必須遵守目錄中的規(guī)定。

他說：“實(shí)施應(yīng)用程序接口的團(tuán)隊(duì)可以選擇他們的數(shù)據(jù)庫和其他很多東西。但如果他們搞砸了，就要追究他們的責(zé)任。你可以非常快速、輕松地判斷一個(gè)團(tuán)隊(duì)的管理是否正確。如果應(yīng)用程序接口出現(xiàn)問題，你就知道出了問題。”

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

通過遵守這三條戒律并借鑒多年的經(jīng)驗(yàn)，IT 領(lǐng)導(dǎo)者可以建立一個(gè)框架，確保每項(xiàng)服務(wù)都有清晰的路徑。消費(fèi)者可以信賴一個(gè)可靠的界面，而生產(chǎn)者則可以獲得構(gòu)建服務(wù)所需的自由。每一方都可以在自己的時(shí)間內(nèi)進(jìn)行創(chuàng)新。