譯者 | 陳峻

策劃 | 梁策、孫淑娟

在我們的常見應(yīng)用中，往往包含著大量服務(wù)于各種數(shù)據(jù)交換的API類型、以及各種常見的API架構(gòu)與協(xié)議。下面，我將從集成的角度和您討論，在準(zhǔn)備將多個服務(wù)相互集成時(shí)，使用不同類型、架構(gòu)和協(xié)議的API意味著什么?我們可以使用哪些工具，又應(yīng)該注意什么呢?

API的類型和集成的復(fù)雜性通常，我們有四種常見的API類型：公共、私有、伙伴和復(fù)合。其中：

1.公共API

公共API有時(shí)也被稱為開放或外部API。顧名思義，任何人都可以公開的方式，在沒有限制、或限制相對較少的情況下使用它。此類API通常是方便第三方與本公司開發(fā)的Web應(yīng)用進(jìn)行通信的一種方式。一些常見的、為大多數(shù)中小企業(yè)提供服務(wù)的公共API有：PandaDoc、BigCommerce、DocuSign、NetSuite等。

2.如何與公共API集成

與公共API集成相對比較容易。不同的公司都會為您提供必要的API文檔，其中描述了各種端點(diǎn)、驗(yàn)證與授權(quán)其API的使用和調(diào)用方法等。事實(shí)上，大多數(shù)企業(yè)的集成平臺都是圍繞著公共API的概念來構(gòu)建的。他們提供的所謂集成連接器，本質(zhì)上都是各個Web應(yīng)用的API抽象層。不過，它們在工作機(jī)制上的復(fù)雜性和范圍，則取決于API的設(shè)計(jì)與文檔說明。

總地來說，與公共API集成相關(guān)的主要策略有兩種：要么像iPaaS那樣使用第三方軟件;要么自行開發(fā)。在您選擇后者時(shí)，請準(zhǔn)備好為數(shù)據(jù)映射(data mapping，https://www.elastic.io/data-mapping-best-practices/)而設(shè)計(jì)的相應(yīng)策略。雖然許多應(yīng)用程序會使用相同的模式，來命名前端的公共字段，但這些字段在后端可能有著截然不同的標(biāo)簽。適當(dāng)?shù)牟呗詰?yīng)該能夠保證追溯性、準(zhǔn)確性和相對快速的項(xiàng)目實(shí)施保障，以及對于一些容易避免的錯誤予以保護(hù)。

值得一提的是，如果您正在為自己的項(xiàng)目尋找一些可公開訪問的API，GitHub上就有一個較為詳盡的公共API列表(https://github.com/public-apis/public-apis)。它涵括了諸如天氣預(yù)報(bào)等Web應(yīng)用所需要用到的、完整的API密鑰和OAuth授權(quán)。

3.私有API

作為公共API的對立面，私有API僅適用于單個公司。企業(yè)開發(fā)人員經(jīng)常使用它們來實(shí)現(xiàn)Web應(yīng)用之間在某種程度上的數(shù)據(jù)交換、提供對企業(yè)數(shù)據(jù)庫和其他內(nèi)部共享服務(wù)的訪問權(quán)限、以及與其他內(nèi)部API通信、或?yàn)楣締T工構(gòu)建內(nèi)部應(yīng)用。

事實(shí)上，越來越多的公司都認(rèn)識到了使用自己的API的價(jià)值。據(jù)此，他們可以節(jié)省更多的時(shí)間和資源，提高應(yīng)用的敏捷性和靈活性，并有助于降低整體運(yùn)營成本。

4.如何與私有API集成

由于私有API通常駐留在具有高度安全性的環(huán)境中，因此與它們的集成需要通過非常嚴(yán)格的防火墻或VPN服務(wù)，來發(fā)起調(diào)用(當(dāng)然首先需要能夠允許外部可以訪問到)。這意味著，如果您想知道本公司的集成中間件是否確實(shí)有用，就應(yīng)該去檢查它是否具有某種安全機(jī)制/層，去訪問本地系統(tǒng)和Web應(yīng)用。

同樣值得注意的是，那些對于公共API的成功至關(guān)重要的某些方面，卻可能在私有API中顯得無關(guān)緊要。例如，由于已被假定為受到了公司現(xiàn)有安全策略的保護(hù)，因此安全性機(jī)制在私有API并不重要。同時(shí)，由于開發(fā)人員經(jīng)常在文檔中使用內(nèi)部或技術(shù)性的名稱，因此版本控制不一定會被包含在設(shè)計(jì)中。

無論您準(zhǔn)備采用手動編碼，還是某個集成式中間件，新加入團(tuán)隊(duì)的成員或其他部門，在集成私有API時(shí)都會面臨一些挑戰(zhàn)。因此，如果您正在負(fù)責(zé)設(shè)計(jì)私有API的話，我建議您像設(shè)計(jì)公共API那樣，去準(zhǔn)備好API的各項(xiàng)最佳實(shí)踐和檢查。

5.伙伴API

伙伴API屬于內(nèi)部API的一個類別，但這些API通常在業(yè)務(wù)伙伴和B2B客戶之間共享，而不是在某個組織內(nèi)自己使用。此類API的一個常見用例是，在供應(yīng)鏈集成或銷售點(diǎn)的集成中，連接兩個內(nèi)部業(yè)務(wù)軟件的應(yīng)用程序。在這種情況下，API往往充當(dāng)?shù)氖墙?jīng)典的EDI(電子數(shù)據(jù)交換，Electronic data interchange)集成的替代方案。

伙伴API通常具有更加強(qiáng)大的授權(quán)、身份驗(yàn)證和安全功能。它們能夠允許外部各方去訪問某些敏感數(shù)據(jù)。例如，伙伴CRM或ERP應(yīng)用的客戶數(shù)據(jù)，或者是醫(yī)療機(jī)構(gòu)患者醫(yī)療數(shù)據(jù)等。

6.如何與伙伴API集成

由于伙伴API不是公開可用的，因此您可能無法找到允許即時(shí)“連接”的集成方案。如果您打算集成此類伙伴API的話，就需要提供良好的手動編碼、或者去尋找支持自助服務(wù)、以及自定義連接器的集成中間件的幫助。

有時(shí)您可能需要將伙伴API與基于EDI的Web應(yīng)用相連接，那么您就需要進(jìn)行諸如從EDIFACT到JSON的各種數(shù)據(jù)格式的轉(zhuǎn)換。當(dāng)然，一個良好的企業(yè)集成平臺，往往能夠支持此類功能。此外，您也可以使用各種專用的解析器，例如：用于UN/EDIFACT文檔的Javascript流解析器(https://openbase.com/js/edifact/documentation)。

7.復(fù)合API

我個人覺得復(fù)合API的使用場景最廣泛。例如在購物車中創(chuàng)建訂單時(shí)，就需要對多個端點(diǎn)進(jìn)行多次API調(diào)用，其中包括：創(chuàng)建新的客戶、創(chuàng)建新的訂單、向該訂單添加新的商品、展示分類商品等。一個復(fù)合API往往可以在一次性調(diào)用中，完成所有這些工作。這無疑加快了多任務(wù)處理的能力和效率。例如，下面是Salesforce的復(fù)合REST API的屬性文件：

{

"compositeRequest" : [{

"method" : "POST",

"url" : "/services/data/v52.0/sobjects/Account",

"referenceId" : "refAccount",

"body" : { "Name" : "Sample Account" }

},{

"method" : "POST",

"url" : "/services/data/v52.0/sobjects/Contact",

"referenceId" : "refContact",

"body" : {

"LastName" : "Sample Contact",

"AccountId" : "@{refAccount.id}"

}

}]

}

在上述文件中，其API在一次性調(diào)用中，最多可以有25個所謂的子請求。

復(fù)合API的另一個實(shí)用場景是，從多個服務(wù)中提取信息，以完成微服務(wù)架構(gòu)模式中的單個任務(wù)。不過，復(fù)合API也不一定需要創(chuàng)建全新的API。在許多情況下，您可以通過在一個序列中包裝多個調(diào)用或請求，來擴(kuò)充現(xiàn)有API的設(shè)計(jì)。

8.如何與復(fù)合API集成

在集成方面，復(fù)合API與常規(guī)公共API并沒有太大的區(qū)別。事實(shí)上，如果您的集成平臺方案已經(jīng)具有被用于REST或SOAP的通用連接器的話，您可以輕松地使用它來連接到復(fù)合API處。

9.與不同的API架構(gòu)和協(xié)議集成

下面，讓我們簡要地討論一下，在使用具有不同架構(gòu)和/或協(xié)議的API時(shí)，該如何定義可接受的數(shù)據(jù)類型和命令。當(dāng)然，在大多數(shù)時(shí)候，您可能會用到REST和SOAP等API。其中，REST是一種架構(gòu)風(fēng)格，而SOAP是一種協(xié)議。它們之間有著各種相似之處，可以通過HTTP和XML進(jìn)行通信，因此彼此的集成非常容易。

當(dāng)然，兩者之間也有著顯著的差異。例如，

• 為了在服務(wù)器上公開Web應(yīng)用業(yè)務(wù)邏輯的特定部分，SOAP會使用服務(wù)接口，而REST則使用URI。
• REST API支持包括：純文本、XML、JSON和CSV在內(nèi)的多種數(shù)據(jù)格式，而SOAP僅支持XML。
• REST通常也被認(rèn)為比SOAP更輕量級、而且消耗的資源也更少。

就兩者的集成而言，我們需要在這兩種API之間進(jìn)行某種“翻譯”。當(dāng)選擇手動集成這些API時(shí)，您可以使用Postman等工具來自動執(zhí)行此類操作。例如，您可以調(diào)用一個Web應(yīng)用程序的SOAP API，并將返回的XML解析為您需要的數(shù)據(jù)。之后，您可以將該XML轉(zhuǎn)換為諸如JSON格式，并將這些數(shù)據(jù)推送到另一個Web應(yīng)用程序的REST API處?？梢姡?dāng)您的公司部署了可以默認(rèn)處理REST和基于SOAP的Web應(yīng)用與服務(wù)之間的數(shù)據(jù)轉(zhuǎn)換集成API之后，它將使您的工作變得更加輕松，應(yīng)用的效率大幅提升。

原文鏈接：https://dzone.com/articles/a-guide-to-api-types-and-integration-specifics