SOAP 1.2 與 GET 請求

出自：IBM 

SOAP 1.2 帶來的變化進一步把 Web 服務編織到 Internet 的大網中。變化之一是 GET 方法的引入。GET 之是以重要是因為它支援各種優化。這一點已經過 Web 自身的驗證，它廣泛地使用 GET 方法。通過本技巧可以進一步了解這一點。

SOAP 1.0 釋出以來，很多人曾經抱怨它對 HTTP POST 方法的依賴。許多人認為 SOAP 利用了一種流行的協定（HTTP），但一點也沒有考慮和了解建立在其上的體系結構。

W3C 主持開發的 1.2 版本解決了這一問題。W3C 曾經在抽象該協定的許多方面花費了大力氣，更容易通過各種不同的技術使用該協定。通過修訂，SOAP 1.2 除了 HTTP 之外還支援 SMTP，并能更好的利用 HTTP。

關于 POST 方法

POST 有什麼問題呢？簡而言之，HTTP 定義了與伺服器互動的不同方法，最基本的方法是 GET 和 POST。事實上 GET 适用于多數請求，而保留 POST 僅用于更新站點。根據 HTTP 規範，GET 用于資訊擷取，而且應該是安全的和幂等的。

在這裡，所謂安全的意味着該操作用于擷取資訊而非修改資訊。換句話說，GET 請求一般不應産生副作用。幂等的意味着對同一 URL 的多個請求應該傳回同樣的結果。完整的定義并不像看起來那樣嚴格。從根本上講，其目标是當使用者打開一個連結時，她可以确信從自身的角度來看沒有改變資源。

比如，新聞站點的頭版不斷更新。雖然第二次請求會傳回不同的一批新聞，該操作仍然被認為是安全的和幂等的，因為它總是傳回目前的新聞。反之亦然。

POST 請求就不那麼輕松了。POST 表示可能改變伺服器上的資源的請求。仍然以新聞站點為例，讀者對文章的注解應該通過 POST 請求實作，因為在注解送出之後站點已經不同了（比方說文章下面出現一條注解）。

GET 與 POST 之間的差別并不總是那麼嚴格，也存在一些共性。許多站點在 POST 請求中封裝了簡單的資訊擷取，可能是因為開發人員認為這樣對他來說更簡單。

盡管關于 HTTP 方法的讨論看起來似乎是抽象的和理論性的，但并非如此。浏覽器和中介軟體（代理、防火牆和内容送出解決方案 la Akamai）根據區分不同請求能力來獲得優化的性能（請參閱參考資料）。

SOAP 結盟 GET

SOAP 最初隻支援 POST 請求。Web 服務仍然能夠實作上述定義的安全服務。比如，查詢訂單進展情況的服務既是安全的也是幂等的。根據 HTTP 規範，它應該作為 GET 請求實作。而根據 SOAP 1.0 則必須使用 POST。

SOAP 1.2 引入了消息交換模式（Message Exchange Patterns，MEPs）和一種新的 HTTP 綁定。兩者相結合就能實作答複 GET 請求的 Web 服務。MEP 描述了客戶和伺服器之間的互動模式。SOAP Request-Response MEP 是一種典型的 Web 服務互動：客戶向伺服器送出請求，伺服器應答。

我将在這裡進一步考察 SOAP Response MEP。MEP 隻定義了一個響應而沒有請求。在實踐中，這意味着請求已經發出，但不是 SOAP 請求，隻有響應是 SOAP。當與新的 HTTP 請求結合時，Response MEP 就可以支援 GET 請求。其工作原理如下：

• 客戶發出 GET 請求。它把

  Accept

  頭設為

  application/soap+xml

  ，以便請求一個 SOAP 答複。
• 伺服器答複，客戶将響應作為正常的 SOAP 響應處理。

伺服器通過

Accept

頭區分 SOAP 請求和正常的 HTML 請求。客戶可以在

Accept

中使用

q

屬性設定不同的 content/type 表明自己的參數選擇。

根據服務的需要，客戶可以通過一般的 URL 編碼方法（通常放在

?

字元後）在 URL 中包含參數。比如，報告伺服器場狀态的服務可能不需要任何參數。按照定義，它傳回目前伺服器的狀态。相反，報告産品可用性和價格的服務就需要産品辨別符（或者名稱）作為參數。

現在您可能迷惑客戶如何知道調用哪個 URL 以及傳遞哪個參數，因為請求并不是 SOAP 的一部分。答案很簡單：SOAP 伺服器應該完成正常 Web 伺服器所做的工作，并在上一次互動中包含該 URL。沒有什麼妨礙 GET 與 POST 的混合與比對。

作為一個例子，想象一個處理辦公用品（筆、紙、剪刀等等）訂單的服務。該服務通過 SOAP 接收訂單，顯然這樣的請求既不是安全的也不是幂等的，是以作為 POST 發出。伺服器的響應可以包含一個 URL 來跟蹤訂單的處理過程。跟蹤是安全的和幂等的，是以最好通過 GET 來實作。

Axis 與 WSDL 支援

在撰寫本文的時候，Axis 僅僅支援 SOAP 1.1，但仍然實作了一種有限的 GET 形式。您可以通過它的 URL 調用任何請求，後面跟上一個

method

參數和其他參數。

比如，假設已經在 URL

http://joker.psol.com/axis/order/Status.jws

實作了訂單狀态服務。該服務有兩個方法，

track

與

detailTrack

，以訂單号（

onumber

）作為參數。我可以通過

http://joker.psol.com/axis/order/Status.jws?method=track&onumber=56544322

調用該服務。

WSDL 2.0（W3C 正在開發）在操作定義中增加了

pattern

屬性。該屬性表明服務支援哪種 SOAP MEP（WSDL 調用 MEP 模式，是以不會在 SOAP 和 WSDL 之間産生混淆）。比如，跟蹤服務可以像清單 1 那樣定義。

清單 1. WSDL 摘錄

<operation name="track" pattern="http://www.w3.org/2003/11/wsdl/out-only"> <output message="trackResponse"/> </operation>

結束語

Web 背後的簡單原理已經證明了自身的靈活性與可靠性。作為 Web 服務中最重要的标準之一，SOAP 與這種取得非凡成功的體系結構的更密切結合，這是一種非常積極的進展。

在等待所青睐的工具包更新到 SOAP 1.2 和 WSDL 2.0 之前，先檢查一下您的 Web 服務，識别出那些遷移到 GET 綁定時作為首要目标的安全操作。

參考資料

• 請參與 Benoit Marchal“使用 XML”專欄的讨論論壇。
• 了解 W3C 如何使 WSDL 2.0 跟上 SOAP 1.2 中的進展。
• 在 W3C 的 XML 協定工作組頁面進一步了解 SOAP。
• 在 W3C 的站點上了解 HTTP 。
• 通路 Brian D. Davison 的 Web Caching and Content Delivery Resources，可以找到關于緩存、代理和内容傳送的許多有用資訊。
• 在“When to use GET?”一文中，Leigh Dodds 記載了 W3C 中關于向 SOAP 增加 GET 支援的讨論。
• 閱讀 Russell Butek 的技巧文章“用 JAX-RPC 發送與接收 SOAP 消息”（developerWorks，2003 年 9 月）。
• IBM WebSphere Studio Application Developer 是一種支援使用不同技術如 XML、JSPTM、Servlet、HTML、Web 服務、資料庫和 EJB 等建構各種應用程式的開發工具。
• 在 developerWorks XML 專區可以找到更多 XML 資源。關于最新 XML 技巧的完整清單，請檢視 實用技巧。
• 從 developerWorks 訂閱每周一期的 Web 服務/XML 技巧郵件。
• 了解如何才能成為一名 IBM 認證的 XML 及相關技術的開發人員。