SOA之（5）——REST的SOA（SOA with REST）概念

時間  2019-11-18
標籤 soa rest 概念 欄目 微服務 简体版
原文   原文鏈接

REST的SOA（SOA with REST）概念

發展

1992年網站（Web Sites）是在Web瀏覽器和Web服務器直接經過HTTP傳輸HTML。html

2000年WS-* （Web Services）是在客戶端和服務器之間基於HTTP傳輸SOAP XML格式的數據，服務端用WSDL來規定契約。json

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）架構

Group Spec Page Count
安全Security 　 　
　 Web Services Security (O) 56
　 UsernameToken Profile (O) 15
　 X.509 Certificate Token Profile (O) 16
　 Policy Language (M) 13
　 Trust Language (M) 41
　 Secure Conversation Language (M) 17
　 Web Services Federation Language(M) 28
　 WS-Federation: Active Requestor Profile (M) 14
　 WS-Federation: Passive Requestor Profile (M) 13
　 Kerberos Binding (M) 17
　 　 　
可靠消息Reliable Messaging 　 　
　 Reliable Messaging (M) 21
　 　 　
事務Transactions 　 　
　 Coordination (M) 16
　 Atomic Transaction (M) 10
　 Business Activity Framework (M) 13
　 　 　
元數據Metadata 　 　
　 WSDL 1.1 (W) 32
　 Policy Framework (M) 15
　 Policy Attachment (M) 10
　 Policy Assertions Language (M) 9
　 Dynamic Discovery (M) 22
　 Metadata Exchange (M) 23
　 　 　
消息Messaging 　 　
　 SOAP 1.2 Primer (W) 39
　 SOAP 1.2 Messaging Framework (W) 47
　 SOAP 1.2 Adjuncts (W) 25
　 Addressing (M) 15
　 MTOM (W) 13
　 Enumeration (M) 27
　 Eventing (M) 21
　 Transfer (M) 17
　 SOAP-over-UDP (M) 7
管理Management 　 　
　 Web Services for Management (M) 23
業務流程Business Process 　 　
　 BPEL4WS (M) 74
配置文檔pecification Profiles 　 　
　 Devices Profile (O) 24
　 WS-I Basic Profile (O) 50
　 　 　
　 TOTAL PAGES:

 

783

正文目錄

什麼是REST？

RESTful的設計

WS-*與REST的比較

討論

前瞻

表述性狀態轉移（REpresentational State Transfer）

REST爲Web定義了一個架構風格

它的四個原則能夠用HTTP協議來實現

  1. URI資源識別（Resource Identification）
  2. 全部資源統一接口（Uniform Interface）
    • GET（狀態查詢、冪等性、緩存）
    • POST（建立子資源）
    • PUT（更新、狀態轉換）
    • DELETE（刪除資源）
  3. 自解釋（Self-Describing），消息的元數據和多種資源表述
  4. 超連接（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的設計方法

  1. 識別資源並暴露成服務（例如，年度風險報表，圖書分類，採購訂單，缺陷，調查投票等）
  2. 定義好的URL供尋址
  3. 理解GET、POST、PUT、DELETE對於一個URI資源的意義
  4. 設計並記錄資源的表述
  5. 用超連接（hyperlinks）爲資源關係建模
  6. Web服務器實現與部署
  7. 用瀏覽器進行測試（固然這裏還有其餘一些好的輔助測試工具，後面能夠專門開文章探討）

一個簡單的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

相關文章
相關標籤/搜索
每日一句
    每一个你不满意的现在，都有一个你没有努力的曾经。
本站公眾號
   歡迎關注本站公眾號,獲取更多信息
聯繫我們 最近搜索 最新文章 沪ICP备13005482号-10 MyBatis教程 SQL 教程 MySQL教程 Java 教程 Thymeleaf 教程 Hibernate教程 Spring教程 Redis教程