英文原文：SOA and API Schism and Unification

　　雖然API和SOA有著相似的商業和技術目標，許多API的支持者卻堅持表示API與SOA幾乎沒什么關聯，認為它們屬于截然不同的方法。他們經常宣揚務實的REST API和SOA之間有著巨大的差異。分工限制了SOA服務和RESTful API無法干凈利索地集成到一個統一的架構中。

　　團隊必須在SOA和API的觀點之間建起一座橋梁，構建一個實際的規劃去融合 API 和 SOA。

　　“做REST”和“創建API”的團隊通常的關注點是，以增量的外部擴展、具體的演示和不涉及復雜技術的核心業務用例來克服技術和業務的障礙。而SOA團隊通常關注的是，獲得擴展效率、達到商業標準、建立決策中心和滿足復雜的非功能性需求。

　　通過結合API和SOA的觀點，當遵循商業策略和擴展需求時團隊就能夠迅速地交付業務解決方案了。

　　務實的REST API關注點

　　REST是一種系統開發的架構風格，它強制實行一系列服務交互的約束。正規的REST約束包括客戶端-服務端和無狀態的交互、可緩存的響應、不變的契約、分層的系統設計和按需編碼。這些約束有利于特性的顯現，也就是簡單性、可擴展性、可變性、可靠性、可見性、性能和可移植性。滿足REST約束的系統稱為RESTful。RESTful設計方法能夠增加許多的收益：

• 使數據和服務更易于訪問
• 降低入門門檻
• 盡最大可能擴展受眾數量
• 使API或服務被大量的用戶代理消費
• 使數據和服務逐步演進
• 在運行期擴展系統
• 對資源的修改不會影響到客戶
• 動態指導客戶行為
• 使系統可擴展、可靠和高性能
• 簡單
• 可緩存
• 原子性

　　雖然RESTful設計有益于支撐SOA的目標，但務實的REST的戰略關注點與許多SOA的舉措不同。務實的REST API設計團隊專注于自下而上的應用場景、友好的協議或格式（比如HTTP、JSON、DNS）、寬容的接口定義和簡單的交互模型（比如在保證送達之上的重試）。

　　務實的SOA關注點

　　務實的SOA專注于面向服務的模式，該模式著重于增加軟件資產的價值。基本的面向服務的模式是：

• 共享和重用資產
• 將冗余的功能固定到穩定的部件中
• 使項目遵守公共標準和最佳實踐

　　應用這三種模式將減少IT環境的復雜度，帶來更大的靈活性，比如，能夠更加快速地構建應用、更加快速地修改以處理需求的變更。面向服務的模式推動開發團隊去評估軟件資產滿足商業干系人需求的能力。

　　務實的SOA最佳實踐

　　務實的SOA團隊不強行推進公共（而且復雜）的標準。務實的SOA團隊提供有價值的商業能力、降低應用的阻力并交付獨特的服務價值。

　　務實的SOA團隊不鼓吹難以操作的最佳實踐。他們依靠團隊間的傳幫帶和自動化的治理以簡化最佳實踐的應用，這使團隊可以更輕松地做正確的事情。

　　務實的SOA團隊會留意技能差異和應用的障礙。他們提供加速器包（比如架構、工具、框架和API或服務構建塊）減少培訓、增加自助服務的應用，以及加快項目的交付速度。

　　務實的SOA團隊會平衡企業治理與項目的自主權。而不是豎立開發和注冊門檻，成功的團隊引入若干機制去改進服務、間接的交互、硬性服務水平并促進自助服務的應用，通過引入這些機制使團隊促進服務的開發、服務的共享和服務的應用。你可以把這些機制當成現有API管理的核心。

　　務實的調和

　　REST與SOA是不同的，雖然它們并非格格不入。服務可以成為RESTful，RESTful資源也可以成為服務。像SOA一樣，REST是由一組設計原則定義的架構規程，REST還強制施行一組架構約束。REST使用以資源為中心的模型，這與以對象為中心的模型截然相反（比如，通過資源來封裝行為）。在REST中，你感興趣的每件事物都是資源。當進行RESTful服務（也叫作API）的建模時，以一組資源來封裝和暴露服務的能力。

　　因為SOA所呈現的架構目標狀態通常與目前遺留的IT資產是有一定差異的，所以SOA是一個漫長的架構之旅，而不是一種短期實現。因為API使組織內外的業務能力相互連通，所以API能夠為商業干系人提供一個平臺，使他們可以在其上發起企業IT革新以及實行務實的業務。

　　什么時候去創建服務或者去創建API

　　當正要創建一個同時包含SOA和REST的統一架構策略時，下一個合乎邏輯的問題是：什么時候去創建服務或者去創建API呢？從消息傳遞的觀點來看，服務和API有相似的屬性。它們都是可訪問的的網絡終端，通過訪問交付數據或觸發事務。從架構的觀點來看，服務和API都提供了分離關注點、創建松耦合解決方案的機會。許多架構師和開發人員都想要隨著API一起擴展他們面向服務的架構（SOA），但并不清楚什么時候去創建服務或者去創建API。

　　什么時候創建服務？

　　作為一個可訪問的網絡終端，一項服務是一項已經發布的業務或者數據。當團隊要跨網絡域或運行期應用共享業務能力或業務數據時，創建服務。

　　服務應當實現一個適當自動化的業務任務，不應該設計成與其他組件交互的精細化組件。當服務暴露了業務流程中的一項獨立任務時，開發人員和業務分析師更喜歡去獲悉服務的目標。以業務任務的粒度去設計服務，減少服務的交互復雜度，簡化應用的維護工作。舉一些適合于面向服務的方法的業務任務的示例，它們包括“提交訂單”、“檢索客戶記錄”以及“繳費”。

　　接口與實現分離

　　服務封裝了特定的實現，服務終端通常在服務與后端業務邏輯之間有一個一對一的關聯關系。服務應該通過多種接口風格（比如面向資源的、發布/訂閱的、方法調用的）暴露業務能力或數據。為了最大化有效性和范圍，服務實現應該通過多種消息協議（比如HTTP、JMS、MQ）和消息格式（比如JSON、XML、CSV）去發布可訪問的接口。

　　RESTful是一種接口風格。這種網絡非常適用于移動應用、瘦JavaScript客戶端應用以及跨網絡和所有域的bash腳本訪問函數。

　　理想情況下，接口風格不僅是詳細的解決方案，還是重要的管理特性（比如安全性、服務層的強制實施、用法跟蹤等），在所有接口風格（比如面向資源的、發布/訂閱的、方法調用的）中這些特性都是有效的。圖1展示了外觀模式，連接了一個單一的服務實現和多個消費者：

圖1：API外觀模式

　　內在表征與外部契約和外部協議的分離，肯定會影響隨著時間去演變服務實現的能力。當從已有的實現中清晰地分離出接口時，開發人員就可以修改其實現而不會影響到使用該服務的應用調用了。

　　然而，從共享的應用平臺消除消費者和提供者的耦合，以及從實現中消除接口耦合都會增加額外的關注點。例如，如果試圖使操作語義（比如身份、服務層、授權）跨不同的平臺和分布式環境無縫地流轉，那么難度就增大了。團隊依靠中間件基礎設施去橋接跨所有參與者和組件的語義。

　　因為從實現中分離接口引入了復雜度和額外的工作量，許多團隊把接口緊緊地綁定在實現上。通過下述的架構最佳實踐，并引入API外觀或代理終端（使用自動化開發），團隊可以增強解決方案的可維護性和適應性。

　　什么時候創建RESTful API？

　　RESTful API是一種與服務實現互補的接口風格。可在以下時機創建RESTful API，當要共享控制領域（比如業務單元、組織）之外的服務時，當以擴大影響范圍和消費群體為目標時，當要提供跨本地web基礎架構的服務時，或者對服務端、接口和實現的不對稱演進極其感興趣時。

　　如果開發團隊發布已有服務前的API外觀，他們要從服務的實現中分離出服務的接口。API端點是實施安全、監控使用和流量整形的輕量級代理。代理使消費者接口合約和后端服務的實現可以清晰地分離。

　　當應用服務器、企業服務總線節點或者數據服務主機可以發布API端點的時候，API網關是由API傳送機制優先管理的。托管的API是：

• 可主動發布和訂閱
• 與相關已經發布的服務級協議（SLA）一起有效
• 安全的、已認證的、已授權的且受保護的
• 通過分析可監控和可貨幣化

　　服務接口或RESTful API接口

　　RESTful API與服務是不一樣的，雖然它們并非格格不入。服務可以成為RESTful，RESTful資源也可以成為服務。像SOA一樣，REST是由一組設計原則定義的架構規程，REST還強制施行一組架構約束。

　　RESTful API接口是服務接口中一個有約束的子集。RESTful API暴露面向資源的接口，理想情況下符合HATEOS（超媒體作為應用程序狀態引擎）。RESTful API發布資源為中心的模型，它與對象為中心的模型相反（比如，行為是以資源來包裝的）。在REST中，感興趣的每樣“事物”都是一個資源。當對一個RESTful服務（也叫做API）建模時，服務的能力作為一組資源進行包裝和暴露。

　　去創建一個RESTful API：

1. 為所有事物指定“ID”
2. 將所有事物鏈接在一起
3. 使用標準HTTP方法
4. 允許多種消息格式的表述
5. 減少共享的狀態

　　新興的API設計工具將幫助你把一個服務實現轉換成一個RESTful API。