簡介

幾乎所有企業(yè)都有多個應(yīng)用程序作為其關(guān)鍵數(shù)據(jù)的記錄系統(tǒng)，而且還擁有它們賴以創(chuàng)業(yè)的業(yè)務(wù)功能。因此，一些組織想要不斷向其企業(yè)內(nèi)外更廣泛的受眾揭示這些操作系統(tǒng)中的寶貴資產(chǎn)，我們對此已司空見慣。但是，這需要時間。在本教程中，我們將介紹這項評估的關(guān)鍵階段，幫助您評估您的企業(yè)在此旅程中的位置，分析您可能想要采取哪些行動來讓您的集成架構(gòu)朝著或超越 API 公開的方向發(fā)展。

首先，讓我們簡要介紹一下業(yè)務(wù)功能公開的歷史，然后更詳細地分析以下兩個最新的概念之間的區(qū)別：面向服務(wù)的架構(gòu) (SOA) 和 Web API。

過去幾十年來，整個行業(yè)在集成架構(gòu)上的進化顯而易見，業(yè)務(wù)功能的公開程度不斷加大，如圖 1 所示。

圖 1. 業(yè)務(wù)功能的漸進式公開

我們的目的是了解 SOA 與現(xiàn)代業(yè)務(wù) Web API 之間的區(qū)別。為了有效地理解此區(qū)別，我們需要明確了解 SOA 帶來了什么。

讓我們簡單看看前 3 個階段（一直到 SOA）發(fā)生了哪些變化，然后分析 Web API 增添了哪些變化。

使用 “低級 API” 的點對點連接

自從企業(yè)擁有應(yīng)用程序，就需要在應(yīng)用程序之間移動和共享數(shù)據(jù)。讓用戶在不同系統(tǒng)中反復輸入信息（“轉(zhuǎn)椅” 集成）在大多數(shù)情況下無助于持續(xù)發(fā)展。這帶來了在孤立的應(yīng)用程序之間建立直接（點對點）低級連接的需求。獲得實時的響應(yīng)常常是不可能的，所以數(shù)據(jù)通常是通過文件或單向消息異步發(fā)送的。每個接口的每一端都需要新的序列化和解析代碼，如圖 2 所示。

圖 2. 點對點集成

應(yīng)用程序之間的不同連線表明，通常需要多個不同的協(xié)議來實現(xiàn)不同的接口，這使集成任務(wù)變得更加復雜。

為此，我們引入了應(yīng)用編程接口 (API) ，包括傳輸、協(xié)議和用于實時交互的數(shù)據(jù)格式，使直接從被調(diào)用的系統(tǒng)獲得響應(yīng)成為現(xiàn)實。當然，這是縮寫詞 API 的起源，API 現(xiàn)在已擁有稱為 “Web API” 的新用途。本教程將明確區(qū)分這兩種 API，將原始類型稱為 “低級 API”，將新類型稱為 “Web API”。在日常用語中，Web API 通常被簡稱為 “API”。

集成的成熟度通常是使用 服務(wù)集成成熟度模型 (SIMM) 來度量的。點對點集成的 SIMM 級別通常為 2。SIMM 是一種成熟度模型，但我們應(yīng)謹慎地理解 “成熟度” 的含義。在您進入下一個級別時，模型中的每個級別上采用的技術(shù)不會過時，它們只是被更有選擇性地使用。例如，即使在實現(xiàn)了 SIMM 級別為 4 的服務(wù)的公司中，仍然可能對偶爾的點對點或中心輻射型集成具有充分合理的需求。

這些低級 API 在不同平臺上具有明顯的區(qū)別，這就需要向每種集成兩端的應(yīng)用程序中寫入復雜的特定于應(yīng)用程序的連接代碼。

企業(yè)應(yīng)用程序集成

在上世紀 90 年代，集成工具和運行時變得越來越常見。它們知道如何執(zhí)行連接，并提供了一個中央集線器來執(zhí)行所有集成。

這實現(xiàn)了一種更加類似 “中心輻射型” 的架構(gòu)，并顯著減少了編寫的專用集成代碼量，如圖 3 所示。這通常具有 SIMM 級別 3，被稱為企業(yè)應(yīng)用程序集成 (EAI)。

圖 3. 中心輻射型架構(gòu)

這些新工具和技術(shù)意味著，您可以在集成集線器范圍內(nèi)重用連接，您只需要確定如何連接到一個應(yīng)用程序一次?？偸鞘褂猛瑯拥墓ぞ吆瓦\行時來完成此工作，而不是在多種語言和多個平臺上使用集成代碼。

由于應(yīng)用程序之間根本不同的交互風格，它們通常沒有實時連接。更常見的是，一個入站適配器從系統(tǒng)獲取數(shù)據(jù)并存儲在基于文件或消息的存儲器中，然后一個集成流處理該數(shù)據(jù)并將其傳遞給目標系統(tǒng)。在數(shù)據(jù)僅需要用于引用用途時，這不可避免地會導致在系統(tǒng)間復制大量數(shù)據(jù)。與原始系統(tǒng)連接的實時接口（real-time interfaces）可減少這種重復。

漸漸地，與操作系統(tǒng)連接的實時接口變得更加普遍，它們減輕了對跨系統(tǒng)復制數(shù)據(jù)的需求。但是，一個新系統(tǒng)要使用這些實時接口之一，仍然需要一些工作來將它連接到集線器。誠然，在中心輻射型架構(gòu)上所做的許多嘗試僅僅稍微減輕了點對點問題，向一個運行時和一個工具中引入了點對點編碼。除非集成是針對重用而小心設(shè)計的，否則創(chuàng)建一個新接口仍然需要大量新代碼。

我們需要一種更加標準化的方式來從集線器公開功能，以便無需額外的工作即可重用它。

面向服務(wù)的架構(gòu)

在 2000 年代初，隨著傳輸、協(xié)議和數(shù)據(jù)格式標準得到更廣泛的采用，比如 SOAP/HTTP（通常稱為 “Web 服務(wù)”），以標準化方式公開服務(wù)成為可能。這意味著請求者（他們理解這些現(xiàn)代標準）通過最小的努力就可以使用這些服務(wù)。這些公開的業(yè)務(wù)功能的直接重用現(xiàn)在已變?yōu)榭赡?。一個經(jīng)過良好控制的公開服務(wù)套件應(yīng)該具有 SIMM 級別 4。

任何重用機會都會帶來新的收益，同時也會帶來新的挑戰(zhàn)。使用 SOAP/HTTP 簡單地公開業(yè)務(wù)功能，不足以確保服務(wù)的健全性。它會帶來許多挑戰(zhàn)，從系統(tǒng)間難以管理的依賴性到安全暴露。

從服務(wù)公開的角度講，SOA 比協(xié)議和數(shù)據(jù)格式的標準化復雜得多。要有效地公開服務(wù)，還需要標準化以下方面：

虛擬化：用戶必須調(diào)用一個隱藏了其最終的實現(xiàn)方式和位置的復雜性的虛擬 服務(wù)端點。向標準化的協(xié)議和傳輸?shù)霓D(zhuǎn)換是虛擬化的一部分，但服務(wù)還需要提供標準的可配置方面，比如路由和數(shù)據(jù)轉(zhuǎn)換，同時繼續(xù)向用戶提供同樣的虛擬 服務(wù)來最小化變更的影響。

可視性：如果公開核心業(yè)務(wù)功能，您需要管理和監(jiān)視它們。要大規(guī)模地實現(xiàn)有效的監(jiān)視，需要在所有服務(wù)上以一種標準化方式來執(zhí)行。

安全性：要讓服務(wù)容易使用且更容易管理，您需要標準化訪問控制、身份管理和其他關(guān)鍵的安全性 方面。安全性是復雜的，而您需要您的服務(wù)容易使用。您需要減少向用戶公開的安全模型的變化。

流量管理：您如何確保高優(yōu)先級用戶始終能夠訪問他們需要的服務(wù)，并獲得可接受的響應(yīng)時間？如果您需要臨時犧牲一個用戶來留住另一個用戶，該怎么辦？您如何管理計劃或計劃外的宕機？您需要對服務(wù)公開點執(zhí)行某種形式的可配置的操作控制，使您無需經(jīng)歷代碼周期即可進行調(diào)整。

這篇教程的開頭已經(jīng)更詳細地描述了這些方面：WebSphere Process Server 和 WebSphere ESB 中的解決方案設(shè)計。

要實現(xiàn)上述所有標準化，您需要正式地分離架構(gòu)中的服務(wù)公開功能，如圖 4 中的服務(wù)公開網(wǎng)關(guān)所示。它可能不是最終的物理架構(gòu)中的一個單獨的運行時組件，但至少需要在設(shè)計中明確地描繪它。必須可以以一流的方式滿足虛擬化、可視性、安全和流量管理需求。

圖 4. 服務(wù)公開

您將注意到，我們在圖 4 中所示圖表中特意未 使用常見的 SOA 相關(guān)術(shù)語，企業(yè)服務(wù)總線 (ESB)。這是因為人們對 ESB 的準確界線存在很大的分歧。畢竟，ESB 是一種架構(gòu)模式，而不是組件描述。有人說，它只是服務(wù)公開網(wǎng)關(guān)，而其他人認為它包含集成集線器。有人認為它也包含適配器，在這些觀點之間還有許多變體。有大量文獻描述了 ESB 模式的細節(jié)，但我們最終發(fā)現(xiàn)，清楚地描述各個具體的組件和它們的職責會更好。

除了 SOA 的運行時組件之外，還有治理方面。如果有大量服務(wù)，您如何決定要公開哪些功能和它們的優(yōu)先級？人們將如何發(fā)現(xiàn)所公開的功能？您如何控制所使用的數(shù)據(jù)模型中的變化？必須保留候選和當前服務(wù)的某種形式的目錄，以實現(xiàn)服務(wù)生命周期的治理。

所有這些擔憂最終可歸結(jié)為，公開服務(wù)不是小事。如果只是簡單地將功能公開為通用的 Web 服務(wù)，則會在可管理性和安全性上帶來大量失敗機會。簡言之，重用具有代價，而且隨之而來的是如何找到 SOA 的問題。任何具有緊張的最后期限和預算限制的項目，都不希望成為首次構(gòu)建某個服務(wù)的項目 - 至少不太合適。

除此之外，事實上，人們實現(xiàn) SOA 概念所需的標準是在 SOA 舉措實施過程中不斷開發(fā)的，因此它們還不夠成熟。在企業(yè)嘗試實現(xiàn)它們的過程中，它們也在不斷改變。很容易看到為什么一些 SOA 難以獲得發(fā)展動力。在許多公司，SOA 被局限在業(yè)務(wù)的一個特定領(lǐng)域，或者實際上只有少量核心服務(wù)在起作用。

JSON/HTTP 接口介紹

基于瀏覽器的應(yīng)用程序變得更加復雜，而且引入了一些機制來編寫功能更豐富、響應(yīng)更迅速的網(wǎng)頁。這些機制利用了瀏覽器愈加成熟的客戶端腳本功能，以及它們使用 AJAX 等技術(shù)執(zhí)行后臺 HTTP 請求來檢索數(shù)據(jù)的能力，而且用戶體驗不會被頁面預加載中斷。

網(wǎng)頁通常通過頁面關(guān)聯(lián)的 Web 服務(wù)器來請求特定于網(wǎng)頁的數(shù)據(jù)。SOA 中常見的 SOAP/HTTP 請求在 JavaScript 中很難處理，而且請求的發(fā)送常常使帶寬很低的 Internet 連接變得不堪重負。執(zhí)行更細粒度的數(shù)據(jù)請求正快速變得流行起來，如果可能的話，可以更改為使用 JavaScript 原生的 JSON 數(shù)據(jù)格式，如圖 5 中的紅色區(qū)域所示。

圖 5. 富瀏覽器應(yīng)用程序的細粒度公開

由于不受 SOAP 標準的限制，這些接口可被視為簡化在要表示的數(shù)據(jù)上執(zhí)行 “動作” 或 “操作” 的方式的備用方式。在一次對 Web 早期根源的有趣的回溯中，HTTP 背后最初的意圖被揭示了出來。HTTP 標準的許多方面是圍繞 Roy Fielding 在 2000 年 提交的具象狀態(tài)傳輸 (REST) 的架構(gòu)原則而設(shè)計的。由此衍生出了一種基于實體的更加簡單化的交互風格。該交互風格推薦以一種與常見數(shù)據(jù)庫交互洞察（創(chuàng)建、請求、更新、刪除）類似的方式，使用常見的 HTTP 洞察（POST、GET、PUT、DELETE）。全球網(wǎng)絡(luò)以一流的方式識別這些洞察，以提供隱含的好處，比如緩存。它還使用 URL 路徑來導航數(shù)據(jù)實體之間的關(guān)系。

在一個更加簡化的示例中，可以想象向一個訂單添加一個商品的過程，可通過向一個 URL 發(fā)出 HTTP “POST” 來執(zhí)行此操作，這個 URL 類似于下面這個 URL：

https://www.mycompany.com/orders/123456/item

HTTP 請求正文中的 JSON 格式數(shù)據(jù)類似于如下形式：

1. { "title" : "Romeo and Juliet", 
2.    "note" " "Special Edition",   "quantity : 1, 
3.    "price" : 9.99 }  

其中 URL 描述了特定的數(shù)據(jù)實體（通常稱為 “資源”），HTTP 動詞 “POST” 的使用意味著它是一個新訂單項的 “創(chuàng)建” 操作。要在 SOAP 中承載同樣的信息，代碼更類似于如下形式：

1. http://www.example.org/ordermanagement HTTP/1.1<?xml version="1.0"?><soap:Envelope xmlns:soap="http://..." soap:encodingStyle="http://..."> 
2.   ...SOAP headers...  <soap:Body xmlns:m="http://www.example.org/ordermanagement"> 
3.     <m:AddOrderItem> 
4.       <m:order orderid="123456" 
5.         <m:item> 
6.           <m:title>Romeo and Juliet</m:title> 
7.           <m:note>Special Edition</m:note> 
8.           <m:quantity>1</m:quantity> 
9.           <m:price>9.99</m:price> 
10.         </m:item> 
11.       </m:order> 
12.     </m:AddOrderItem> 
13.   </soap:Body></soap:Envelope>  

與之前出現(xiàn)的越來越復雜的 SOAP 標準相比，這些基于 JSON/HTTP 的接口提供了一些有用的簡化。但是，SOAP 擁有更龐大的 標準集合，它們可完成這些接口做不到的許多事情。它們被不同的受眾使用，而且不是所有這些標準在該領(lǐng)域都是必要的。

至少在最初，這些新接口的可重用性上存在一些限制。由于瀏覽器實現(xiàn)的 同源策略，基于網(wǎng)頁的應(yīng)用程序很難（但不是不可能）向其他公司提供的接口發(fā)出 HTTP 請求。這意味著，這些基于 JSON/HTTP 的接口最常見的初始用途，是用在公司的網(wǎng)頁與其自己的企業(yè)數(shù)據(jù)之間。但是，一些技術(shù)（比如代理、JSONP）和標準（比如 CORS）減輕了這些限制，使這些接口能夠得到更廣泛的重用，使 “Web API” 變成了現(xiàn)實。

什么是 Web API？

對于 “Web API” 的準確含義，沒有正式的定義，就像在它之前的 “Web 服務(wù)” 一樣，但我們會盡量明確它的含義。

大體上講，“Web API” 通常指通過以下方式公開的功能和數(shù)據(jù)：

通過 HTTP(S) 公開

以 REST 風格使用 HTTP 協(xié)議

使用 JSON 作為數(shù)據(jù)格式

可通過互聯(lián)網(wǎng)使用

對于如今任何創(chuàng)建新 Web API 的人，這可能是您的起點。但是，從某些層面上講，此定義過于簡單：

不是所有 Web API 都使用 JSON：大多數(shù) API 都使用 JSON 作為數(shù)據(jù)格式，但一些 API 提供 XML 作為一種備用格式，或者甚至惟一地使用 XML。在理論上講，HTTP 可響應(yīng)的任何請求都是有效的。如果您包含 MIME 類型（舉例而言，這可能意味著使用 PDF 文件），這種更廣泛的用途不那么常見。

不是所有 Web API 都是公共的：我們在后面的一節(jié)中將會看到，API 不僅在公共互聯(lián)網(wǎng)上公開和使用。但是，可以合理地認為，風格、用法以及受支持產(chǎn)品和協(xié)議上的許多一致意見都是互聯(lián)網(wǎng)用途所推動的。

不是所有 Web API 都直接使用 HTTP 的 REST 風格的特性：有許多面向互聯(lián)網(wǎng)的 SOAP/HTTP 接口，而且很難否認，這些接口在某種形式上也是 Web API。它們或許不那么 “REST 化”，而且更難使用。但是，許多 SOAP/HTTP 接口隨后引入了 JSON/HTTP “REST 風格的” 等效功能。

很少有 Web API 是完全 REST 風格的：在 Web API 中使用 JSON/HTTP，這意味著肯定比以前更加 REST 化。因此，它們通常被稱為 “REST” 接口。但是，實際上，大多數(shù)接口僅符合 有關(guān)該主題的原始材料 中描述的部分 REST 建議。針對自稱 REST 化的 API 的一種常見抱怨是，它們很少提供 HATEOS 方法所推薦的鏈接。

強烈推薦使用 HTTPS：HTTPS 顯然是首選的，而且許多人認為是 Web API 的強制要求。有效負載通常包含私有數(shù)據(jù)，用于訪問 Web API 的憑據(jù)通常是機密的。

所以出現(xiàn)了一種新的、更加輕型的協(xié)議和交互風格，但單單此協(xié)議和交互風格無法為向?qū)崟r數(shù)據(jù)集成的演化保駕護航。

讓 Web API 變得成熟的觸發(fā)因素是什么？

在 2007 年左右擁有容易訪問的 “應(yīng)用程序” 商店的智能電話成為主流時，業(yè)界發(fā)生了重大變化。移動應(yīng)用程序（“app”）開發(fā)得以普及，而且龐大的開發(fā)人員群體都可以參與開發(fā)。除了一些明顯的例外，應(yīng)用程序很少能單獨運行。它們需要與周圍世界交互。開發(fā)人員如果擁有簡單的途徑來整合對其他公司提供的數(shù)據(jù)和功能的訪問，他們就能夠編寫強大得多的應(yīng)用程序。

這不僅是來自移動應(yīng)用程序開發(fā)人員的要求，功能更豐富的網(wǎng)站的開發(fā)人員也需要更廣泛、更輕松地訪問數(shù)據(jù)。但是，移動通常會帶來大量新的 Web API 用戶。他們沒有安全限制方面的阻礙，這些阻礙給基于瀏覽器的應(yīng)用程序中的 API 使用帶來了一些挑戰(zhàn)。所以，您可以認為，Web API 的引入有兩種重要影響：需求和能力。

新的賺錢方式：受（但不僅限于）新一代移動服務(wù)使用者的流行所推動的新興盈利性融資模型，這些使用者表現(xiàn)為電話、平板電腦、手表等的應(yīng)用程序的形式，都需要訪問實時的數(shù)據(jù)和功能。

成熟的能力：經(jīng)過十年來在可重用服務(wù)公開上的努力，公開業(yè)務(wù)功能的標準、技術(shù)和方法已發(fā)展成熟。舉例而言，協(xié)議和數(shù)據(jù)格式的公開在不斷試驗中逐漸成熟。API 的公開網(wǎng)關(guān)現(xiàn)在可用作一個一級組件，而且它擁有得到廣泛認可的職責范圍。

Web API 與之前的 API 有何區(qū)別？

正是在新需求及其關(guān)聯(lián)的融資模型中，大數(shù)據(jù)發(fā)揮著重要作用。公開的業(yè)務(wù)功能的受眾位于企業(yè)外。如圖 6 所示，SOA 服務(wù)更常見的是在企業(yè)內(nèi) 公開，一般基于一個項目漏洞和它們各自已知的需求。Web API 通常在外部 向常常未知且可能龐大的用戶群公開，通常用于高度創(chuàng)新性和無法預料的用途。

圖 6. 影響在企業(yè)外公開服務(wù)的新因素

如果一個 Web API 可提供對一個應(yīng)用程序有用的數(shù)據(jù)，那么它對其他應(yīng)用程序可能也有用。將這些服務(wù)（或 API）放在網(wǎng)絡(luò)上，而且 Web API 突然會獲得整個互聯(lián)網(wǎng)的潛在用戶，甚至可到達許多以前無法接觸到的細分客戶群。這離不開新的融資模型。我們有機會從這些公開的業(yè)務(wù)功能中牟利。Web API 變成了組織提供的一種新 “產(chǎn)品”。

投資回報可能具有許多不同的形式：

直接收入：例如，一個用于購買商品的 Web API。

間接收入：例如，通過向其他服務(wù)商提供聚合服務(wù)來贏得傭金。

成本節(jié)?。豪?，實現(xiàn)自助服務(wù)來精減一個昂貴的客戶服務(wù)的應(yīng)用程序。

市場營銷：例如，將產(chǎn)品信息放在更龐大的客戶群面前。

可以肯定的是，通過將應(yīng)用程序設(shè)計師的創(chuàng)新眾包到企業(yè)外，可獲得新的市場。

您如何迎合對您的集成架構(gòu)的需求的這一重大變化？

這個公開組件對 Web API 有何不同？

基于 Web API 的早期定義，您可以看到，與企業(yè)服務(wù)相比，在公開外部 Web API 時有 3 個重要方面將發(fā)生根本性改變：

超出企業(yè)界線：Web API 用戶不是企業(yè)的一部分，所以他們不受您的直接影響和控制。

無數(shù)的用戶：您的 API 的潛在用戶比企業(yè)服務(wù)的用戶多得多。

競爭性市場：如果您的 Web API 無法滿足用戶的期望，他們擁有其他公司所提供的替代選擇。在擁有 SOA 的企業(yè)內(nèi)，他們可能僅有一個選擇。

這些關(guān)鍵的不同會導致您架構(gòu)和設(shè)計 Web API 的方式發(fā)生大量的修正。在本教程中，我們主要關(guān)注架構(gòu)的區(qū)別。在架構(gòu)上，您顯然仍然需要某種形式的公開網(wǎng)關(guān)，但對該網(wǎng)關(guān)的需求擁有一些新元素。

回想本教程之前的內(nèi)容，重用始終是有代價的。從圖 7 中可以看出，您的公開能力需要擴展到核心 SOA 需求以外。

圖 7. 針對企業(yè)外的公開 API 的新能力

我們看看這些新挑戰(zhàn)的兩個主要方面：

合作伙伴管理：您現(xiàn)在擁有一個龐大的移動應(yīng)用程序設(shè)計師團隊，其中的設(shè)計師可能想要試驗?zāi)?Web API。如果不將它設(shè)計得非常容易使用而且具有吸引力，您的 Web API “產(chǎn)品” 很快就會被競爭對手趕超。您如何與這些新合作伙伴建立新關(guān)系？您如何持續(xù)跟蹤誰在訪問這些功能？您可能擁有外部相關(guān)方依靠您的 Web API 作為其業(yè)務(wù)的基礎(chǔ)部分。您如何建立和監(jiān)視他們需要何種服務(wù)水平？合作伙伴管理必須是 Web API 公開組件提供的一個一級功能。由于潛在合作伙伴的龐大數(shù)量，合作伙伴管理必須是自助式的，它還需要識別合作伙伴，依據(jù)達成一致的授權(quán)計劃來監(jiān)視和控制他們的使用情況。

安全性：顯然，通過公共媒介（比如互聯(lián)網(wǎng)）公開 Web API 意味著需要考慮全新的安全問題水平，從各種以有效負載為載體的攻擊，比如 XML 威脅，到對吞吐量或連接的拒絕服務(wù)攻擊。您還必須可靠地驗證您合作伙伴的應(yīng)用程序，以便有效地控制其服務(wù)水平。

這種增加的復雜性導致了現(xiàn)在所謂的 API 管理 的出現(xiàn)。Web API 管理是一種架構(gòu)意圖，而不是單個組件，盡管它們顯然是 專為該意圖而設(shè)計的產(chǎn)品。它使組織能夠簡單而又安全地公開和管理 Web API。它將一種更健全、更安全的網(wǎng)關(guān)與和合作伙伴管理相關(guān)的功能相結(jié)合。

圖 8 顯示了實現(xiàn) API 管理所需的主要組件，以及所涉及的典型角色。

圖 8. API 管理的一個典型模型的示例

所有這些角色都在 SOA 中以一種或另一種形式松散地呈現(xiàn)，但它們的實現(xiàn)通常不那么正式。Web API 面向公眾的事實已迫使它們變得成熟。典型的角色集合為：

API 產(chǎn)品經(jīng)理：此角色建立適合銷售的 Web API，準備和管理其使用 “計劃”，以及使用歷史分析評估 Web API 的成功。

API 開發(fā)人員：此角色通過配置與提供實際數(shù)據(jù)和功能的后端系統(tǒng)的連接性和數(shù)據(jù)映射，提供 Web API 表面背后的實質(zhì)。

應(yīng)用程序開發(fā)人員：此角色通過 “API 門戶” 在產(chǎn)品上利用 Web API，簽署協(xié)議以通過 API 產(chǎn)品經(jīng)理定義的一個計劃使用它們。

運營：此角色每天監(jiān)視和管理 Web API，確保它們滿足該計劃所定義的服務(wù)水平。

API 表面背后的架構(gòu) “實質(zhì)” 是什么？

Web API 網(wǎng)關(guān)只是 Web API 的表面或暴露點。它沒有提供 Web API 所提供的任何實際功能或數(shù)據(jù)。這讓我們能夠了解集成架構(gòu)在企業(yè)內(nèi)演化的全過程 - 從孤立的應(yīng)用程序成長為點對點通信和中心輻射型中間件，進而潛在地實現(xiàn) SOA。

誠然，在決定 Web API 的底層實現(xiàn)應(yīng)來自何處時，高度依賴于企業(yè)的演變方式。圖 9 顯示了最常見的選項的例子：

重新公開一個現(xiàn)有的企業(yè)服務(wù)

公開一種通過集線器調(diào)節(jié)的新集成

公開一個已由提供商系統(tǒng)提供的接口

圖 9. Web API 實現(xiàn)的選項示例

人們很容易認為重新公開現(xiàn)有服務(wù)（圖 9 中的選項 A）是最常見的。畢竟，SOA 已存在 10 多年，肯定大部分公司都已擁有一套服務(wù)。公開這些服務(wù)將是從以前對集成的投資中獲利的最高效方式。盡管肯定有一些組織在這么做，但由于以下原因，這可能沒有您預料的那么常見：

集成成熟度：前面已經(jīng)提到過，服務(wù)通常僅在業(yè)務(wù)中它們具有價值的特定部分中公開。對于業(yè)務(wù)的其他部分，其他集成模式（比如中心輻射型或者甚至點對點模式）可能仍然夠用。

粒度：因為企業(yè)服務(wù)通常是根據(jù)已知的業(yè)務(wù)需求而創(chuàng)建的，所以它們通常具有很粗的粒度，帶來一個相對較大的數(shù)據(jù)圖，而且可能包含許多子對象。這些操作對移動設(shè)備上需要的響應(yīng)迅速的應(yīng)用程序而言負擔太重，尤其是考慮到設(shè)備常常變化的帶寬。

安全性：企業(yè)服務(wù)執(zhí)行更新操作時，該操作常常以一種特定于企業(yè)的方式執(zhí)行；例如，假設(shè)呼叫方的可信度，信道的安全性，或僅供內(nèi)部使用的安全令牌機制。

相關(guān)性：在公司內(nèi)值得關(guān)注的或可銷售的數(shù)據(jù)和功能，通常是無關(guān)的或不適合外部公開。我們在 Web API 中尋找的通常是一種全新的市場機會；一個可能公開完全不同的數(shù)據(jù)的新概念。

因此，圖 9 中的選項 B 可能很常見，而且 Web API 使用集成來實現(xiàn)。或許他們在集成集線器本身內(nèi)重用組件和適配器，但未重用現(xiàn)有服務(wù)。

選項 C 目前很少見，因為想要的 Web API 幾乎肯定不同于現(xiàn)有應(yīng)用程序。Web API 網(wǎng)關(guān)通常擁有有限的數(shù)據(jù)轉(zhuǎn)換功能。但是，一旦集成邏輯遠遠超越基本的數(shù)據(jù)映射和簡單聚合，Web API 網(wǎng)關(guān)在架構(gòu)上就不再適合此邏輯。

基于云的 API 管理

在當今時代，人們渴望減少內(nèi)部基礎(chǔ)設(shè)施占地空間，企業(yè)在尋找更容易從基于云的提供商獲得的功能。API 管理是一個不錯的例子。Web API 網(wǎng)關(guān)和 API 管理功能都擁有明確的責任，所以它們很容易與內(nèi)部架構(gòu)分開，如圖 10 所示。因為目標是向外部相關(guān)方公開它們，所以托管來自基于云的提供商的 Web API 具有一定的合理性。

圖 10. 基于云的 API 管理服務(wù)提供商

盡管與具體企業(yè)相關(guān)，但這種基于云的 API 管理特別適合 “誕生于網(wǎng)絡(luò)” 的公司。舉例而言，一家創(chuàng)業(yè)公司選擇不建立內(nèi)部基礎(chǔ)設(shè)施，將所有功能托管在基于云的環(huán)境中?；谠频?API 管理使他們能夠提供單個統(tǒng)一的公開點來供用戶查找他們的 Web API，無論這些 API 托管在云中的何處。

使用此方法，您需要考慮以下因素：

訪問控制：您如何向基于云的 API 管理服務(wù)安全地提供訪問您的內(nèi)部中間件或?qū)嶋H操作系統(tǒng)的能力？顯然，需要某種形式的安全連接器，但您準備交給外部相關(guān)方多大的控制權(quán)？

延遲：Web API 的用戶現(xiàn)在需要在互聯(lián)網(wǎng)上進行兩次跳躍，才能到達您的站點：第一次跳躍到 Web API 提供商，然后再跳躍到您的組織。Web API 似乎更加 “口語化”，這意味著您通常需要執(zhí)行更多調(diào)用來達到相同的目的。因此，更多的最終用戶在等待與通信延遲相關(guān)的時間。依賴于服務(wù)的全球覆蓋范圍和 Web API 交互通常的繁忙程度，這種額外的延遲可能很高。API 管理解決方案常常提供了緩存選項來為適合該模式的請求減少此延遲。

企業(yè)內(nèi)的 API - SOA 中的下一個階段？

新的 “REST” 風格的 JSON/HTTP 接口更加輕量型，適合且受現(xiàn)代編程語言和框架支持。API 管理網(wǎng)關(guān)產(chǎn)品越來越成熟。為什么還要在企業(yè)內(nèi)利用所有這些優(yōu)點？許多人現(xiàn)在將內(nèi)部 API 管理層視為一種替代方案，而且在一些情況下，是一種在企業(yè)內(nèi)公開數(shù)據(jù)和功能的更有效方式 - 圖 4 中所示的服務(wù)公開網(wǎng)關(guān)的擴展。

圖 11 顯示了實現(xiàn)內(nèi)部和外部 API 的單一管理點所需的最低限度的架構(gòu)配置。這帶來的附加優(yōu)勢是，內(nèi)部用戶可直接使用外部公開的 API，而無需路由到互聯(lián)網(wǎng)。事實上，企業(yè)常常仍然更喜歡擁有單獨的內(nèi)部和外部 API 網(wǎng)關(guān)，以實現(xiàn)更可靠的關(guān)注分離。

圖 11. 針對內(nèi)部和外部用戶的 API

所以對一些人而言，API 已成為其公司內(nèi)朝面向服務(wù)的架構(gòu)發(fā)展的旅程中的下一個階段，以及它們實現(xiàn)外部公開的機會。

一種新的 B2B 形式

另一個值得考慮的案例是，不斷成熟的 Web API 技術(shù)和實踐被用于提供業(yè)務(wù)間 (B2B) 通信。B2B 接口從任何角度講都不再新穎。幾十年來，企業(yè)已使用了各種標準來交換數(shù)據(jù)，比如與電子數(shù)據(jù)交換 (EDI) 相關(guān)的標準。由于針對特定行業(yè)需求的專門化，用于實現(xiàn)它們的標準和工具必然非常深入和復雜。許多企業(yè)需要一種更加輕量型的備用方案來交換數(shù)據(jù)，但它們?nèi)匀恍枰獫M足一些核心需求，比如安全功能和合作伙伴自助管理。即使公司未計劃向一般大眾提供 API，對 API 管理的安全性和合作伙伴管理方面的利用可能對實現(xiàn)與特定業(yè)務(wù)合作伙伴的簡單的私有接口很有價值。

超越 Web API

嘗試猜測由于最近幾年此領(lǐng)域的技術(shù)進步，集成架構(gòu)會如何發(fā)展，會很困難且可能很愚蠢。但是，這似乎涉及到進一步認識移動用戶近期的現(xiàn)狀。一個重要因素是，對于更龐大的社區(qū)，人們對 “始終在線” 的渴望仍轉(zhuǎn)變?yōu)?“間歇性連接”。

這意味著基于消息的事件驅(qū)動的交互的復興。我們已看到更多基于事件訂閱的交互模型。例如，所有主要移動供應(yīng)商都擁有向設(shè)備推送事件的機制。傳感器現(xiàn)在能夠在得到更廣泛認可的協(xié)議中發(fā)出事件，比如傳感器與事件訂閱者之間不那么專門的耦合。“物聯(lián)網(wǎng)” 正在一切事物中都引入傳感器，從可穿戴技術(shù)到互聯(lián)汽車，再到一種不同類型的應(yīng)用程序。這些可能不太關(guān)注從操作系統(tǒng)中獲取的特定數(shù)據(jù)，而更重視密切注意所關(guān)注的主題，智能地解釋所收到的事件。

結(jié)束語

回頭看看 圖 1，您可以看到集成架構(gòu)如何實現(xiàn)向更多的公眾漸進地公開業(yè)務(wù)功能，還可看到用于實現(xiàn)這一公開的功能的不斷成熟。API 管理是這一領(lǐng)域的最新技術(shù)，認識到不斷開發(fā)的模式、技術(shù)和概念（比如中心輻射型架構(gòu)和 SOA）在正確的情況下仍有用且合適，這很重要。