面向資源與面向活動的 Web 服務

每當一些 Web 應用程式服務提供者提出允許開發人員整合他們的服務的 Web 服務 API 時，大家都非常關心由 API 實現的互操作設計模式。如果 API 使用的是 REST 樣式的互操作，REST 方法的擁護者就會將該 API 作為說明為什麼 REST 樣式服務比 SOAP 樣式服務更優越的重要例子而加以稱讚；同樣地，如果 API 使用 SOAP 樣式 Web 服務模式，情況也類似。似乎很少有人關心這樣的一個事實，模式的選擇主要取決於正在被執行的應用程式的類型，並且像所有優秀的體繫結構決策一樣，開發人員應該將他們的選擇基於正在被開發的應用程式的特定技術需求和特性，而不是基於針對單一體繫結構方法的一些特殊偏好。

資源還是活動？

從基本原理層次上說，REST 樣式和 SOAP 樣式 Web 服務的區別取決於應用程式是面向 資源的還是面向 活動的。

面向資源服務集中於明確的資料對象，一些基本、標準的操作可以依據這些資料對象而執行。如權威的 Gang of Four（GoF） 設計模式這本書所述，對於熟悉物件導向設計模式概念的開發人員來說，面向資源服務與基本 Memento 模式類似。實際上，服務提供者維護一組資源，並且公開一組基本操作來執行以下任務：

• 檢索資源

• 修改資源

• 建立新資源

• 刪除資源

根據定義，REST 樣式 Web 服務是面向資源的服務。您可以通過統一資源識別項（Universal Resource Identifier，URI）來識別和定位資源，並且針對這些資源而執行的操作是通過 HTTP 規範定義的。其核心操作包括：

• GET - 該操作返回已標識資源的狀態表示。您可以通過大量的上下文要素來確定狀態，例如誰正在提交請求、操作的參數（傳入的參數如 HTTP 頭或者查詢字串參數）和服務提供者維護的當前工作階段狀態。

• POST - 該操作執行對已標識資源的一些特定於應用程式形式的更新。該操作行為完全依賴於實現它的服務。由該操作返回的資料也完全依賴於應用程式。舉例來說，像 GET 操作一樣，它可以返回一個狀態表示，它還可以選擇根本不返回任何資料。

• PUT - 該操作在已標識位置（URI）建立新資源。操作輸入必須包括一個資源的狀態表示。它完全依賴服務來建立基於這個狀態表示的資源。

• DELETE - DELETE 操作銷毀已標識位置（URI）的資源。

在許多方面，REST 樣式 Web 服務與 SQL、元組空間（tuple spaces）、簡單訊息列隊等技術相似。它們都使用普通的簡單操作針對明確的資源起作用。

• SQL - SELECT、INSERT、DELETE、UPDATE 等

• 元組空間 - GET、PUT

• 訊息列隊 - SEND、RECEIVE

在每一個案例中，服務介面的設計允許您移動關於資源的資訊，讓其依賴於請求方來指出希望通過這些資訊來做什麼。

與此相對的是 面向活動的資源。該類型的應用程式集中於您可能執行的操作，而不是集中於操作所依靠的資源。活動服務的一個簡單的例子就是銀行事務，在那裡使用者可以把錢從一個賬戶轉移到另一個賬戶上。使用者不想直接操作資源（錢、銀行賬戶等等），他們只想告訴銀行他們想要達到的目的，並且讓銀行根據他們的利益對資源進行處理。用 GoF 術語來描述應用程式：

• 命令

• 中介方

• 策略

• 代理設計模式

面向資源服務不管資源的類型怎樣，執行的操作可以保持相對不變，與面向資源服務不同，面向活動服務的操作完全依賴於正在執行的活動類型。例如，銀行服務可以公開一個名為 transferFunds 的操作，該操作不同的輸入將完全決定服務的資金轉移功能。

在面向資源的服務中，一組普通操作擔當支援性的工作角色，為用戶端提供訪問和操作資源。然而，資源是關注的中心，如下面 圖 1 所示。

圖 1. 面向資源服務與面向活動服務的比較

在面向活動服務中，對用戶端請求執行的每個活動的單一操作來說，操作是關注的中心。

SOAP 樣式 Web 服務通常是面向活動的。 WSDL 文檔定義並描述特定於服務的操作。操作由特定於服務的訊息交換組成。每一個操作都是一個可以執行的活動。那些正在被執行的操作所針對的內容通常是不相關的。正如 Web 服務資源架構系列規範所描述的，資源可以隱含在活動之中，但是這種隱含與活動的定義不相關，並且只是為了改進執行活動所依賴的上下文。與針對資源而執行活動的面向資源服務相比，它和用來訪問資源的服務介面互不相關。

來自： 

http://www-128.ibm.com/developerworks/cn/webservices/ws-restvsoap/?ca=dwcn-newsletter-webservices