REST的SOA（SOA with REST）概念
發展
1992年網站（Web Sites）是在Web瀏覽器和Web服務器直接通過HTTP傳輸HTML。
2000年WS-* （Web Services）是在客戶端和服務器之間基於HTTP傳輸SOAP XML格式的數據，服務端用WSDL來規定契約。
2007年RESTful （Web Services）是在客戶端和服務器之間基於HTTP傳輸JSON、PO-XML、RSS格式的數據，服務端用WADL來規定契約。
Web services從哪來？
解決企業軟件標准化的問題
企業計算的互用性標准
一個提供消息、描述、發現規范的分層架構
能夠快速從底層構建提供解決方案
工具可以將復雜性屏蔽
處理異構（Heterogeneity）
Web應用（Web Applications）與 企業計算（Enterprise Computing）
龐然大物（Big Web Services）
- 復雜難以理解（High perceived complexity）
- 標准化存在問題
- 斗爭中（infighting）
- 缺乏架構的一致性（architectural coherence）
- 碎片化（fragmentation）
- 設計委員會（committee）
- 特性膨脹（feature bloat 主要提現在不斷新增的文檔）
- 缺乏參考實現（reference implementations）
- 標准的標准（Standardization of standards (WS-I)）
- 看似另一個CORBA？
- Web services的互用性真的存在？
- 我們真的需要采用XML來提升性能？
一個關於Web Services文檔的不完全統計（http://www.tbray.org/ongoing/When/200x/2004/09/21/WS-Research）
正文目錄
什么是REST？
RESTful的設計
WS-*與REST的比較
討論
前瞻
表述性狀態轉移（REpresentational State Transfer）
REST為Web定義了一個架構風格
它的四個原則可以用HTTP協議來實現
- URI資源識別（Resource Identification）
- 所有資源統一接口（Uniform Interface）
- GET（狀態查詢、冪等性、緩存）
- POST（創建子資源）
- PUT（更新、狀態轉換）
- DELETE（刪除資源）
- 自解釋（Self-Describing），消息的元數據和多種資源表述
- 超鏈接（Hyperlinks），定義應用的狀態轉換和資源之間的關系
一個RESTful Web Service的例子
統一接口原則（CRUD的例子）
創建（POST《-》）——創建一個子資源
讀取（GET《-）——獲取當前資源的狀態
更新（PUT -》）—— 初始化或更新一個URI對應的資源狀態
刪除（DELETE）——清除一個資源（在一個URI失效之后）
統一資源標識符URI（Uniform Resource Indentifier）是什么？
- 因特網對於資源命名和標識的標准
例如：
http://tools.ietf.org/html/rfc3986
http——統一資源標識符方案（URI Scheme）
://tools.ietf.org——授權（Authority）通常是一個主機名
/html/rfc3986——路徑（Path）
https://www.google.ch/search?q=rest&start=10#1
?q=rest&start=10——查詢（Query）
#1——片段（Fragment）
- REST並不擁護“好”的URI
- 在多數HTTP棧中URI的長度不能大於4Kb
什么是“好”的URI？
URI的設計指南
- 名詞（Nouns）優於動詞（Verbs）
- URI保持簡短
GET /book?isbn=24&action=delete
DELETE /book/24
- 遵從位置通過參數傳遞的方案
REST URI對於客戶端透明的意思是它是由后續的鏈接提供，而不是通過客戶端自行創建
- 不要改變URI
- 真的需要改變時，用重定向實現（redirection）
注意：URI模板引入了客戶端和服務端的耦合
高級REST 和 低級REST
關於REST實現的最佳實踐有些區別（在本人實際工作中，很多技術實力雄厚的大型企業，對於REST最佳實踐的方案也基本可以歸為以下兩種，而第一種“低級”REST比較普遍）
低級REST（Low REST）
- 用HTTP GET實現冪等請求，其他所有請求都用POST（沒有HTTP PUT DELETE等其他方法）
- 響應格式（MIME Type）多種多樣（e.g. XHTML, application/json, application/xml）
高級REST（High REST）
- 推薦使用好的URI
- 充分使用4個動詞：GET、POST、PUT和DELETE（*）
- 響應體用（Plain Old） XML（**）
補充說明：
（*）有些防火牆或者HTTP的代理可能丟棄PUT/DELETE請求
（**）XML可以被RDF、JSON、YAML或者ATOM（ATOM存在很大的爭議）替代
資源表述的格式XML vs. JSON
| XML | JSON（JavaScript Object Notation） |
| —PO-XML | 為AJAX Web應用引入格式供（瀏覽器－Web服務器通訊） |
| —SOAP（WS-*） | |
| —RSS，ATOM | |
| 半結構化的數據和標准的文本語法 | 文本語法支持序列化非循環的數據結構 |
| 工具：XML Schema，DOM，SAX，Xpath，XSLT，Xquery | 有很多語言支持（不僅僅JavaScript） |
| 每個人都可以解析它（不需要理解） | 不需要擴展 |
| 慢、臃腫 | JSON已經成為AJAX中的X而不是XML |
一個JSON的例子
REST 的優與劣
| 優勢（Strengths） | 劣勢（Weakness） |
| 簡單 —統一接口不可變更 |
混亂（區分high REST和low REST) |
| HTTP／POX 無處不在 | 在前后台系統設計中存在不匹配的情況（異步消息和事件驅動） |
| 無狀態／同步交互 | 除了HTTP／SSL不能實現其他的企業應用的風格(*) |
| 可擴展 | |
| 易於理解並采用（輕量級） —只需要一個瀏覽器，不需要WS中間件 |
對於合適的識別和定位所有應用中的資源時一個挑戰 |
| 朴素的方法(grassroot approach) | 缺乏標准（本人認為REST是一個設計風格而非標准） |
| 被所有的Web2.0應用采用 —85%的客戶都喜歡Amazon的RESTful API —Google不再支持SOAP／WSDL API |
語法和語義的描述是非正式的（面向用戶的） （本人認為這也恰恰是一個優勢） |
(*) 關於企業的應用風格（-ilities）參照文章http://www.cnblogs.com/richaaaard/articles/5006681.html
是否不能實現我們還有待探討
關於RESTful Web Services的設計方法
- 識別資源並暴露成服務（例如，年度風險報表，圖書分類，采購訂單，缺陷，調查投票等）
- 定義好的URL供尋址
- 理解GET、POST、PUT、DELETE對於一個URI資源的意義
- 設計並記錄資源的表述
- 用超鏈接（hyperlinks）為資源關系建模
- Web服務器實現與部署
- 用瀏覽器進行測試（當然這里還有其他一些好的輔助測試工具，后面可以專門開文章探討）
一個簡單的Doodle API例子
- 創建一個投票
- 查詢一個投票
- 參加投票並創建一個新的子投票資源
- 更新一個一有投票（訪問控制頭沒有顯示）
- 當投票結果和決定產生后，投票可以將其刪除
更多的信息可以查看Doodle API: http://doodle.com/xsd1/RESTfulDoodle.pdf
（當然在RESTful下也有很多其他的API實現）
REST設計的相關小貼士
- 理解GET、POST、PUT
- GET 是一個只讀操作。它可以重復執行多次而不影響資源的狀態（冪等性），也可以被緩存
- POST是一個讀寫操作，可以改變資源的狀態，也會讀服務器產生影響
- PUT 是一個寫操作，但問題是如何正確的使用PUT？因為 PUT /resource/{id}可以被多個客戶端並發調用，如何保證資源{id}的唯一性？
- 多種表述形式的妥協（Content-Type）
- 通常客戶端可以提供自己可以處理的格式列表 Accept: text/html, application/xml, application/json
- 服務端則自己選擇最合適的響應格式200 OK Content-Type: application/json 服務端通常通過資源表述不同的后綴形式提供不同的內容格式(只是一個best practice而不是標准)
- GET /resource.html
- GET /resource.xml
- GET /resource.json
- 異常處理（Idempotent vs. Unsafe）
主要體現在HTTP的標准響應碼上
對於GET、PUT、DELETE這些冪等操作，可以執行多次而不會對服務端的狀態產生其他影響，可以在服務器宕機或者出現內部錯誤而恢復過后，重新發起這些請求。對於POST這種非冪等操作就需要在出現異常之后特殊處理，在有些場景下，它也可以被設計成冪等操作來實現：
B = GetBalance() // safe B = B + 200$ // local SetBalance(B) // safe
總而言之，對比WS-*和REST
就是一個蘋果和一個橘子的對比。一個是中間件互用性的標准，另一個是Web架構的風格。
那我們還是來比較一下SOAP和REST吧
- 先舉例
- 概念比較
- REST作為鏈接
- 技術性比較
- 服務的表述
- 安全
- 狀態管理
- 異步消息
舉一個RESTful Web 應用的栗子
同樣的場景下WS是這樣的
REST和SOAP最主要的區別在於
- 對於REST而言，Web是一個任何人都能訪問的信息
—應用需要把它的信息通過URI發布到網絡
- 對於WS而言，Web是任何傳輸的消息
—應用可以與網絡交互，但是他們處於網絡之外
REST是一種鏈接方式
他們（REST vs. SOAP）是如何描述服務的呢？
| REST | SOAP |
| REST是基於人類可讀的文檔，它定義了請求的URI和響應（XML，JSON） | 客戶端的stubs可以通過WSDL的描述用大多數語言生成 （實際上SOAP也是一種XML，也是可讀的） |
| 需要大量的測試和調試，因為URI是手工創建的 （是否有相關工具） |
每個服務都根據自己的語法發布自己的接口 |
| 我們為什么需要強類型的消息？ （如果客戶端和服務端都很清楚傳輸的內容是什么） |
強類型 |
| WADL | WSDL1.1（整個開放端口對於GET和POST是統一的） |
| XML 足夠了？（實際上有JSON、XML等其他） | WSDL2.0（更靈活，每個方法的GET or POST可選） |
REST和SOAP安全對比
| REST | SOAP |
| REST的安全就是HTTPs | SOAP的安全定義在WS－Security中 |
| 被證明的（SSL1.0 自1994） | XML加密 |
| XML簽名 | |
| —徹底的互用性沒有意義 | |
| —性能？ | |
| 點到點安全（認證、完整和加密） | 端到端安全，不需要HTTPs |
一直爭論的狀態還是無狀態
| REST | SOAP |
| 顯性的狀態轉換 | 隱性的狀態轉換 |
| —通信是無狀態的 | —服務端可以保持狀態 |
| —資源數據包含了有效的狀態鏈接 | —消息只包含數據 |
| —客戶端根據鏈接來獲取並維護狀態 | —客戶端根據服務端的狀態機邏輯來維護自己的狀態 |
| Session技術 | Session技術 |
| —Cookies（HTTP Headers） | —Session Headers（非標准） |
| —URL Re-writing | |
| —表格字段隱藏 |
異步可靠的消息
- 對於REST來說，HTTP是一個同步的協議，但是它也可以模擬異步消息
POST /queue 202 Accepted Location: /queue/message/1230213 ____________________________ GET /queue/message/1230213 DELETE /queue/message/1230213
- SOAP消息可以通過異步協議傳輸（比如，JMS、MQ等）
- WS－Addressing可以用來定義獨立的傳輸點
- WS－ReliableExchange定義了一個可靠的傳輸協議（SOAP headers）
REST 和SOAP/WS*的相似點
| REST | SOAP |
| XML | O/XML 綁定 |
| 其他的方式JSON、YAML、RDF | |
| XML Schema | 數據格式的契約需要和接口一起定義 |
| HTTP | 盡管REST認為SOAP誤用了POST |
| 松耦合可擴展 | SOAP提供同步異步方式 |
| SOAP認為統一的接口不會改變 |
揭露所謂的秘密
- 許多REST的擁躉認為REST和Web service是不相兼容的
- 實施上：SOAP和WSDL的新版本已經將Web services設計得更“RESTful”
- SOAP1.2
- Response MEP
- Web Method
- WSDL2.0
- HTTP綁定新增了操作級別（per－operation）對於GET、POST指定
- 增加對於safe／cacheable的屬性標簽
- 但是想讓RESTful完全使用Web services還是很困難
（然而市面上有些產品實際上可以支持他們的相兼容）
總結和前瞻
- SOA可以用不同方式實現
- 關注架構如何解決問題以及這些相關標准的價值，而非具體架構和技術的盲從
- SOAP/WS-* 與 REST都有自己的優勢和適合的應用場景
- 未來會有融合兩種技術優勢的中間件技術出現（新SOAP和WSDL標准）
參考：
《SOA設計模式》 由Thomas Erl及其他供稿者合著，作為Thomas Erl關於面向服務計算叢書的一部分，於2009年1月由Prentice Hall出版，ISBN 0136135161，版權所有2009 SOA System Inc.。
Web Services and Service Oriented Architectures@2009 Cesare Pautasso