雲端API REST與 SOAP

雲端計算的API 層次

API 共有四種層次，開發者在每一層次關注的任務及資料結構不同。

層次 1 – 網絡：在這個層次，開發者直接撰寫網絡格式的要求，若服務以 REST
為基礎，開發者能創造適當的 HTTP 標頭資訊、建立要求內容、並開啟連結服務
的 HTTP，REST 服務回覆資料時，會附上 HTTP 回應碼，因為許多 REST 服務
很直接，故在這個層次撰寫程式碼時相對有效率。
若服務以 SOAP 為基礎，開發者建立 SOAP 信封、加上適當 SOAP 標頭，再將
資料內容加入主體，SOAP 服務回覆時，是以 SOAP 信封裝載要求結果，使用SOAP 服務時，必須分析信封內的 XML 內容，因此會使用較高層次的 API 來呼叫多數 SOAP 服務。

層次 2 – 特定語言工具箱：開發者在這個層次使用特定語言工具箱，以配合
SOAP 或 REST 的要求，雖然開發者仍專注於網絡內部的資料格式與結構，許多
細節已交由工具箱處理，例如處理回應程式碼、計算簽章等。

層次 3 – 特定服務工具箱：開發者使用較高層次的工具箱，並與特定服務配合，開
發者在此層次能夠專注於企業物件與企業程序，開發者若專注於組織相關的資料與
程序，而非網絡協定，效能會高出許多。

層次 4 – 非特定服務工具箱：這是最高層次的 API，開發者使用多重雲端運算供應
者的共同介面，和層次 3 相同，開發者專注於企業目標及企業程序，但與層次 3
不同的是，層次 4 開發者不需擔心雲端服務項目，使用非特定服務工具箱撰寫的
應用程式，應該不需更動或只更動一小部分，就能轉移至不同的雲端供應者


REST (Representational State Transfer) 是一種分散式的軟體架構風格 ,不是一種標準,也不是一種協定,是一種設計模式，一種風格。
概念來自於Roy Thomas Fielding 
Architectural Styles and the Design of Network-based Software Architectures》一文
Fielding認為，對於使用HTTP承載應用程序協議穿越防火牆，XML-RPC 和SOAP所採用的方式是「從根本上被誤導的概念。」它們所採用的方式違背了設立防火牆的概念，結果是，防火牆廠商為了保護系統需要偵察出所承載的協議。由於大多數SOAP應用程序使用HTTP都是為了穿越防火牆，因此，你可以發現REST與SOAP之間的衝突是從哪裡開始的。Fielding認為，如果你打算使用HTTP的話，就應該與充分利用HTTP本身的含義。

Fielding指出，使用且符合代表性狀態傳輸(REST)設計約束的 Web 上部署的組件，可以充分利用 Web 的有用特性，萬維網(World Wide Web)才能夠達到最佳的工作效果。可以這樣理解REST——當一個瀏覽器得到並且顯示構成HTML頁面的各個元素時，它正在獲取資源的當前狀態的表現形式。在Fielding的博士論文中，他列舉了REST風格的設計約束，並且解釋了為什麼這些約束能夠充分利用Web 的有用特性，使其達到最佳狀態，以及這些約束的關鍵所在。同時，在論文中，他也包含了一些關於REST和某些目前的Web風格之間 「不符合」的討論，以及這些Web風格是如何導致設計無法利用Web特性的。

REST 把軟體視為 "資源"(Resource)，以 URL (Uniform Resource Locator) 定位資源所在處。資源的使用者則藉由 HTTP 協定中所定義的"方法"(method)操作資源。
同時在 HTTP 中，也定義了四種基本方法，即 GET, POST, PUT, DELETE,以上四種基本方法大致上對應了四種資料處理動作，即 Create, Read, Update, Delete REST

REST 特點如下

1.資源是由URI來指定。
2.對資源的操作包括Create、Retrieve、Update和Delete資源，這些操作正好對應HTTP協議提供的POST、 GET、PUT和DELETE方法。
3.資源的表現形式則是XML或者HTML，取決於讀者是機器還是人
4.Web Service的Client端主要還是Web流覽器
REST的優點
1.可以利用緩存Cache來提高響應速度
2.通訊本身的無狀態性可以讓不同的伺服器的處理一系列請求中的不同請求，提高伺服器的擴展性
3.瀏覽器即可作為客戶端，簡化軟體需求
4.相對與其他疊加在HTTP協議之上的機制，REST的軟體依賴性更小
5.不需要額外的資源發現機制
6.在軟體技術演進中的長期的兼容性更好
RESTful
REST (REpresentational State Transfer) 的概念來自於 Roy Thomas Fielding 寫的一篇文章 《Architectural Styles and the Design of Network-based Software Architectures》。 其概念結合了 HTTP 與 URL 兩種協定，以及如何運用於網路軟體架構設計。
以 URL 定位資源，根據 HTTP 內容指示操作動作與回應訊息。一個符合上述實作方式的網路服務，就稱之為 RESTful web service 。 有些文章則更進一步，將 ATOM 協定也加了進來，主要是看上 ATOM 格式的特點，將之運用於資源內容的更新工作。 有些 RESTful 文章還會強調要透過 HTTP Authorization 限制使用者存取資源的權限，而不是用表單加 Cookie。



什麼是SOAP？
SOAP（Simple Object Access Protocol）是以XML為基礎的RPC（Remote Procedure Call）與訊息交換機制，雖然支援多種通訊協定，不過一般仍以HTTP為主。1998年SOAP制定初期，微軟扮演主要的推手，並在1999年底推出SOAP 1.0版。2000年5月IBM與其他業者加入W3C，參與制定SOAP 1.1的規格，這對Web Services而言是意義相當重大的里程碑。由於IBM也是Java及J2EE規格制定的重要成員，它的參與代表Web Services規格不再由微軟單一廠商主導。


SOAP（Simple Object Access Protocol ）簡單對像訪問協議是在分散或分佈式的環境中交換信息的簡單的協議，是一個基於XML的協議，它包括四個部分：SOAP封裝(envelop)，封裝定義了一個描述消息中的內容是什麼，是誰發送的，誰應當接受並處理它以及如何處理它們的框架；SOAP編碼規則（encoding rules），用於表示應用程序需要使用的數據類型的實例; SOAP RPC表示(RPC representation)，表示遠程過程調用和應答的協定;SOAP綁定（binding），使用底層協議交換信息。

WSDL（Web Service Description Language）Web 服務描述語言。在這之前，尚不存在一種機制，使一個業務能自動發現其預期夥伴提供的服務。而如今的電子商務需要一種解決方案來描述以下問題：
‧您的在線業務提供什麼服務？
‧您如何調用業務服務？
‧當用戶調用您的業務服務時，該業務服務需要他／她提供什麼信息？
‧用戶將如何提供這些必需信息？
‧服務將以什麼格式發送返回給用戶的信息？


在使用REST？

現在使用REST風格的站點包括Yahoo、flickr、del.icio.us API，Ebay和Amazon同時具有REST和SOAP接口。但在Amazon大約有85%的應用使用REST API，O』Reilly的CEO Tim O』Reilly 也認為開發人員喜歡更簡單的REST，他說在複雜的場合的確用soap更適合，但他更喜歡入門門檻較低的易被廣大用戶人群使用的REST。
在用使SOAP？
google的一些服務在使用SOAP，blogger還使用XML-RPC，還有很多的企業軟件也用SOAP.

 　
一些REST & SOAP 整理優點

 REST web services are:

•Lightweight - not a lot of extra xml markup
•Human Readable Results
•Easy to build - no toolkits required

SOAP also has some advantages:
•Easy to consume - sometimes
•Rigid - type checking, adheres to a contract
•Development tools

相關文章
http://www.runpc.com.tw/content/content.aspx?id=105324
http://cloud-gateway.sys-con.com/node/1233158/mobile



基於SOAP和WSDL的Web Services規範多而複雜，雖然它是標準的，但是用戶頭疼，學習曲線陡而長，應用構建時間長。簡單就是美，易用性是金。在java企業應用開發領域， EJB的沒落，Spring框架的興起和流行印證了這一規律。同樣，在SOA領域這一規律也已起作用，興起了另一種簡單的實現——REST，雖然它不是標準的。





其實REST和SOAP各有所長。REST簡單、易用，與互聯網思想一脈相承，核心思想是資源共享、面向資源的Web Services。而SOAP是廣為接受的標準，在互操作性方面，解決複雜的系統集成方面優勢明顯，其核心思想是面向活動的Web Services。
以前，REST和SOAP的爭論異常激烈。如google選擇SOAP；而Amazon 85％的web services應用採用REST，15％採用SOAP。
但慢慢地廠商變得越來越聰明，逐步擺脫理論上的爭論，看重實際的接受度。