精品国产一级在线观看,国产成人综合久久精品亚洲,免费一级欧美大片在线观看

簡介

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

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

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

圖 1. 業務功能的漸進式公開

我們的目的是了解 SOA 與現代業務 Web API 之間的區別。為了有效地理解此區別，我們需要明確了解 SOA 帶來了什么。

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

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

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

圖 2. 點對點集成

應用程序之間的不同連線表明，通常需要多個不同的協議來實現不同的接口，這使集成任務變得更加復雜。

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

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

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

企業應用程序集成

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

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

圖 3. 中心輻射型架構

這些新工具和技術意味著，您可以在集成集線器范圍內重用連接，您只需要確定如何連接到一個應用程序一次。總是使用同樣的工具和運行時來完成此工作，而不是在多種語言和多個平臺上使用集成代碼。

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

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

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

面向服務的架構

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

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

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

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

可視性：如果公開核心業務功能，您需要管理和監視它們。要大規模地實現有效的監視，需要在所有服務上以一種標準化方式來執行。

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

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

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

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

圖 4. 服務公開

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

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

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

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

JSON/HTTP 接口介紹

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

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

圖 5. 富瀏覽器應用程序的細粒度公開

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

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

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

HTTP 請求正文中的 JSON 格式數據類似于如下形式：

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

其中 URL 描述了特定的數據實體（通常稱為 “資源”），HTTP 動詞 “POST” 的使用意味著它是一個新訂單項的 “創建” 操作。要在 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>  

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

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

什么是 Web API？

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

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

通過 HTTP(S) 公開

以 REST 風格使用 HTTP 協議

使用 JSON 作為數據格式

可通過互聯網使用

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

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

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

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

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

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

所以出現了一種新的、更加輕型的協議和交互風格，但單單此協議和交互風格無法為向實時數據集成的演化保駕護航。

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

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

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

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

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

Web API 與之前的 API 有何區別？

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

圖 6. 影響在企業外公開服務的新因素

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

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

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

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

成本節省：例如，實現自助服務來精減一個昂貴的客戶服務的應用程序。

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

可以肯定的是，通過將應用程序設計師的創新眾包到企業外，可獲得新的市場。

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

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

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

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

無數的用戶：您的 API 的潛在用戶比企業服務的用戶多得多。

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

這些關鍵的不同會導致您架構和設計 Web API 的方式發生大量的修正。在本教程中，我們主要關注架構的區別。在架構上，您顯然仍然需要某種形式的公開網關，但對該網關的需求擁有一些新元素。

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

圖 7. 針對企業外的公開 API 的新能力

我們看看這些新挑戰的兩個主要方面：

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

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

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

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

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

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

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

API 開發人員：此角色通過配置與提供實際數據和功能的后端系統的連接性和數據映射，提供 Web API 表面背后的實質。

應用程序開發人員：此角色通過 “API 門戶” 在產品上利用 Web API，簽署協議以通過 API 產品經理定義的一個計劃使用它們。

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

API 表面背后的架構 “實質” 是什么？

Web API 網關只是 Web API 的表面或暴露點。它沒有提供 Web API 所提供的任何實際功能或數據。這讓我們能夠了解集成架構在企業內演化的全過程 - 從孤立的應用程序成長為點對點通信和中心輻射型中間件，進而潛在地實現 SOA。

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

重新公開一個現有的企業服務

公開一種通過集線器調節的新集成

公開一個已由提供商系統提供的接口

圖 9. Web API 實現的選項示例

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

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

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

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

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

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

選項 C 目前很少見，因為想要的 Web API 幾乎肯定不同于現有應用程序。Web API 網關通常擁有有限的數據轉換功能。但是，一旦集成邏輯遠遠超越基本的數據映射和簡單聚合，Web API 網關在架構上就不再適合此邏輯。

基于云的 API 管理

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

圖 10. 基于云的 API 管理服務提供商

盡管與具體企業相關，但這種基于云的 API 管理特別適合 “誕生于網絡” 的公司。舉例而言，一家創業公司選擇不建立內部基礎設施，將所有功能托管在基于云的環境中。基于云的 API 管理使他們能夠提供單個統一的公開點來供用戶查找他們的 Web API，無論這些 API 托管在云中的何處。

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

訪問控制：您如何向基于云的 API 管理服務安全地提供訪問您的內部中間件或實際操作系統的能力？顯然，需要某種形式的安全連接器，但您準備交給外部相關方多大的控制權？

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

企業內的 API - SOA 中的下一個階段？

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

圖 11 顯示了實現內部和外部 API 的單一管理點所需的最低限度的架構配置。這帶來的附加優勢是，內部用戶可直接使用外部公開的 API，而無需路由到互聯網。事實上，企業常常仍然更喜歡擁有單獨的內部和外部 API 網關，以實現更可靠的關注分離。

圖 11. 針對內部和外部用戶的 API

所以對一些人而言，API 已成為其公司內朝面向服務的架構發展的旅程中的下一個階段，以及它們實現外部公開的機會。

一種新的 B2B 形式

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

超越 Web API

嘗試猜測由于最近幾年此領域的技術進步，集成架構會如何發展，會很困難且可能很愚蠢。但是，這似乎涉及到進一步認識移動用戶近期的現狀。一個重要因素是，對于更龐大的社區，人們對 “始終在線” 的渴望仍轉變為 “間歇性連接”。

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

結束語

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