小朱® 的技術隨手寫

Web Service，這個從 2001 年開始被微軟炒起來的分散式元件概念，隨著 Visual Studio 2002 (.NET Framework 1.0) 的推出得到了軟體龍頭微軟的背書，一個原本要從 SOAP 和 XML 開始打造的可重覆使用 (reusable) 式軟體元件就在 .NET Framework (System.Web.Services 命名空間) 的精美包裝下，讓開發人員只需要使用 [WebMethod] 就能夠寫出自己的 Web Service 元件，一切看似完美的表象之下，卻包裝著殘酷的事實：它很肥，又很複雜 (PS: 約耳的抽象滲漏法則)。

Source: http://msdn.microsoft.com/en-us/library/x05s00wz(v=vs.80).aspx

Web Service 的核心是植基於 SOAP (Simple Object Access Protocol) 的協定之上，SOAP 的結構由 XML 所組成，所以不會 XML 根本看不懂 SOAP，而想靈活的操控 Web Service 又不能不會 SOAP，像是利用 SOAP header 來做使用者認證，或是在使用 Web Service 上傳檔案時顯示進度列等 (使用 Web Service 傳檔案又是另一個故事了)，這些都是要對 SOAP 有一部份的了解後，才會知道要怎麼做的一些案例，撇開這些不談，就算是一個簡單的 Hello World Web Service 好了，光是 SOAP 訊息的通訊，解譯，執行 Web Service 方法，編譯，回傳再於用戶端解譯，這些工作所需要的網路傳輸量和時間就很可觀了，在這兩年輕量化 Web 介面與 AJAX 的興起，Web Service 傳輸量重的問題已經浮上檯面，雖然有些 JavaScript Library 可以直接呼叫 Web Service，然而它卻已經不是輕量級 Web 服務的開發介面首選。

而 REST API (Represental State Transfer) 則是相對於 Web Service 的另外一面，REST API 藉由 URL 與 HTTP 動詞 (GET, POST, PUT, DELETE) 來決定服務端要執行的動作，與 Web Service 最大的不同，就是它不必死綁著 SOAP 協定，服務端只要在 HTTP 動詞以及 URL 規範好，通常服務端不需要做太多額外的處理，同時透過 HTTP Header 的資訊，服務端可以做更多的控制 (ex: OAuth 就是使用 HTTP Header 傳輸 Authorization 標頭)，需要傳輸的資料就會在無形中最小化，尤其適合 mashup application 或 AJAX application 使用，看現在 Google, Facebook, Twitter 與微軟等主流廠商廣為應用即可得之端睨，同時 REST API 配合 JSON 或是少量的 XML，亦可以達到組織資料的目的，而且它能夠跨越到手機等行動應用上，這點是 Web Service 較難做到的。

然而 Web Service 仍有存在的必要，因為 Web Service 發展較久，基礎建設十分完備，包含來自 WS-I (Web Service Interoperability) 組織的規範制訂，安全性的規範完備，且有許多大型應用程式會依賴 Web Service 進行資料交換，所以 Web Service 十分適合在企業應用程式間交換資料或做流程操作，SOAP 與 XML 可以確保格式的正確性與完整性，同時 XML-Sig 規格可以確保訊息的安全性。REST API 就十分適合前端應用程式與服務之間的資料交換以及與使用者互動的部份，它也可以有效的降低開發人員的學習門檻 (當然，基本的 HTTP, Script 與 AJAX 還是要會)。

References:

1. http://en.wikipedia.org/wiki/Web_service

2. http://en.wikipedia.org/wiki/Open_API

3. http://en.wikipedia.org/wiki/Representational_State_Transfer

4. http://ajaxpatterns.org/RESTful_Service