由SOAP說開去 - - 談談WebServices、RMI、RPC、SOA、REST、XML、JSON

引子：

關於SOAP其實我一直模模糊糊不太理解，這種模模糊糊的感受表述起來是這樣：

1. 在使用web服務時（功能接口），原本我就能夠經過安卓中固有的http類（使用http協議），來發送http請求，而且解析返回的數據（通常是xml或者json），獲得我要的結果
2. 爲何還非得畫蛇添足使用soap呢，並且soap本身的介紹也說，它其實沒有發明技術，它其實就是http+xml
   1. 在安卓中使用soap的方法是：（下載第三方類庫），裝配一個soap請求體，使用soap包裝過的http類，經過http把請求體發送出去，而後解析返回的soap數據，取出裏邊的xml數據，獲得我要的結果
3. 因此說人家好好的http，你無緣無故在頭尾包裝一個soap（有點像加一個沒有做用的信封，由於HTTP原本就自帶信封），這不就是沒事收保護費嗎，不嫌煩麼。（但其實我分析到這發現只是收了一個保護費，我表示還算能夠接受吧，畢竟你們都交了）

因而我詳細查閱了網上的資料，結合本身的理解，概括整理以下，引用部分過於零散，就未標示，還請諒解

---

 

要好好談SOAP，就必須從其源頭開始，它的源頭就是WebServices（Web服務）

 

1.Web服務

最先的軟件都是本地軟件，只運行在本地電腦上，直到網絡技術誕生它也只是利用網絡傳送資料，這以後網絡技術獨自發展網頁WEB本身發展了好多年，直到你們發現網絡技術不僅是用來看看網頁，還能夠把網絡技術更深地應用進本地軟件中，深刻地跟本地軟件的功能結合，拓展本地軟件的功能，Web服務的概念就是在這種環境下興起的。

 

Web服務 簡單地說,，就是服務器如何向客戶端提供服務，現有的實現方式能夠分爲三類：

1. SOA 面向服務的架構【面向消息】
2. RPC  遠程過程調用的架構（remote procedure call）【面向方法】
3. REST 表徵狀態轉移的架構（Representational state transfer）【面向資源】

 

1.1.其餘相關概念

RMI

1. 使用java的程序員，對於RMI（RemoteMethod Invoke，遠程方法調用）必定不陌生，在java中，爲了在分佈式應用開發時，可以方便調用遠程對象，java提供了RMI的API。在 RMI 中,遠程對象按照好象它是本地行事，客戶機應用程序會直接調用遠程對象存根上的方法，所以，調用起來就如本地對象同樣方便。RMI中封裝了對象和請求的網 絡傳送，使得異地的對象服務直接可用。
2. 但RMI的使用必須是在可以識別java代碼的環境下使用，即必須有JVM的支持。所以，他只適合在java程序間的對象通訊。若是不在 Java 環境下工做,或者須要與非 Java 環境通訊，那麼SOAP、RPC、CORAR等都是能夠的。.
3. RPC（Remote Method Invocation，遠端過程調用） 與RMI的區別很明顯，相比於RMI直接獲取遠端方法的簽名，進行調用的方式，RPC使用的是C/S方式，發送請求到服務器，等待服務器返回結果。
4. 通訊方式：遠程對象按照好象它是本地行事.客戶機應用程序直接調用遠 程對象存根上的方法
5. 優勢：遠程對象按照好象它是本地行事，編譯期能夠檢查錯誤
6. 缺點：只能基於java語言。異常信息容易丟失。客戶機與服務器緊耦合。

 

2.SOA

SOA 是前幾年炒的很火的一個詞, 不亞於當前的 Cloud Computing , 若是說 RPC 是基於方法調用(method),那麼 SOA 則是基於 消息, 基於方法調用一般會與特定的程序語言 耦合起來,然後者則與具體的實現語言無關, 因此在必定程度上獲得大公司的支持

 

 

3.RPC

3.1總覽：

1. RPC 即遠程過程調用, 很簡單的概念：像調用本地服務(方法)同樣調用服務器的服務(方法).
2. 通常的過程是：向服務器發送一個過程調用的方法及其參數，獲得服務器返回的方法執行的結果
3. 通訊方式：通常直接用底層的TCP，這樣更加快速，這是相比REST只能用HTTP的優點，但它也可用HTTP

3.2.實現方式：

1. XML-RPC
   1. XML－RPC是一個用XML消息執行RPC的簡單協議，服務請求使用XML來編碼，並經過HTTP　POST發送，XML響應被嵌入HTTP響應主體。
   2. 在 Web服務發展的初期，XML格式化消息的第一個主要用途是，應用於XML-RPC協議。XML- RPC中，客戶端發送一條特定消息，該消息中必須包括名稱、運行服務的程序以及輸入參數。（相反， REST風格的請求卻不關心正在運行的程序是什麼，它僅僅請求命名資源）
2. JSON-RPC
   1. JSON-RPC是基於JSON格式的消息交換，JSON比XML更加輕巧，而且很是容易在頁面JS中使用，其餘特色與XML-RPC相似
   2. XML-RPC , JSON-RPC的通訊方式相同， 所不一樣的只是傳輸數據的格式，JSON格式更加易用
3. SOAP協議
   1. XML- RPC只能使用有限的數據類型種類和一些簡單的數據結構。人們認爲這個協議還不夠強大，因而就在使用HTTP的XML-RPC的基礎上發展出了更增強大的 SOAP協議，雖然其最初的定義是簡單對象訪問協議。以後，你們逐漸意識到SOAP其實並不簡單，並且也不須要必須使用面嚮對象語言，因此，如今人們只是沿用SOAP這個名稱而已，它常常被用於一些比較複雜的系統之上
   2. SOAP是在計算機之間交換信息的基於XML的協議，主要側重於經過HTTP傳輸RPC。它利用了XML的命名空間和XML模式(XML Schema)，比XML-RPC更具適用性，可以支持更多的類型及數據結構。
   3. 簡單的說，SOAP定義瞭如何將一個對象編碼成一種格式並經過一種協議傳送到另外一個地方並還原的規範。
   4. 固然不少東西都是現成的，對象編碼後的格式是XML，傳輸的應用層協議是HTTP。 HTTP也並無定義如何在網絡上進行通訊，其所使用的是TCP協議，TCP也沒有定義在路由之間如何傳輸包，那是IP協議。
   5. 但SOAP也不是什麼新東西都沒有，譬如對象如何序列化成爲XML格式，遠程過程調用（RPC）如何實現等，都是SOAP協議的一部分。
   6. XML- RPC只有簡單的數據類型集，取而代之，SOAP是經過利用XML Schema的不斷髮展來定義數據類型的。同時，SOAP也可以利用XML 命名空間，這是XML-RPC所不須要的。如此一來，SOAP消息的開頭部分就能夠是任何類型的XML命名空間聲明，其代價是在系統之間增長了更多的複雜 性和不兼容性。
   7. 最 初，SOAP是做爲XML-RPC的擴展而發展起來的，它主要強調的是，經過從WSDL文件中所得到的方法和變量名來進行遠程過程調用。如今，經過不斷 進步，人們發現了更多的使用SOAP的方式，而不只僅是採用「文件」方式（只是使用一個SOAP信封來傳送XML格式化文件）。不管如何，要掌握 SOAP，瞭解WSDL所扮演的角色是最根本的，看後邊的WSDL
   8. SOAP與XML－RPC對比
      1. XML－RPC是啓動Web服務最容易的方法，在不少方面比SOAP更簡單易用，但不一樣於SOAP的是，XML－RPC沒有相應的服務描述語法，這妨礙了XML－RPC服務的自動調用
      2. SOAP 有明顯的優越性：它很是適合異步通訊和針對鬆耦合的客戶機和服務器。但這種好處會招致一些不利結果。必須作大量的運行時檢查，並且開發人員喪失了許多能夠確保方法和參數是正確的編譯時便利。
      3. 能夠認爲SOAP是XML-RPC的高級版本，兩者基於相同的原理：利用HTTP + XML封裝進行RPC調用
   9. 安全與SOAP
      1. 若是企業使用SOAP來傳送有價值的信息的話，那麼，安全就是最重要的問題。由OASIS組織發起，計算機行業的領導者們已經聯合開發了一套標準，稱爲WS-Security。這個標準對基本的SOAP通訊作出了改善，以便可以處理如下幾個問題：
         1. 消息機密性——因爲攔截HTTP消息的方式很是多，所以，在請求和響應過程當中，必須可以對全部重要信息加密。很幸運，如今的加密技術很是先進，咱們可以對消息內容進行加密，以保證消息不被修改。
         2. 客戶和服務身份——必須可以覈實SOAP請求來源的身份。

 

3.3.其餘相關概念

yar

yar是PRC的一個框架，相似webservice的，能夠遠程調用方法，返回的數據不僅僅是字符串，能夠是數組等類型。

比方說，當你的項目很是龐大的時候，有些公用的模塊就須要對外提供接口。

一、能夠用curl方式調用，接口返回xml格式、或者json格式的字符串，調用方本身去解析。

二、能夠用使用yar寫的方法，直接返回結果，就跟調用代碼自己的方法同樣，能夠返回字符串、數組等格式。

 

Web服務描述語言-WSDL

WSDL(Web Services Description Language)是描述web服務的，是描述怎樣訪問web服務的。WSDL是用來描述SOAP的，換句話說，WSDL 文件告訴你調用 SOAP 所須要知道的一切。WSDL也是一段xml。如今各個語言對wsdl的支持都很成熟，能夠根據同一份wsdl文件生成本身語言的客戶端。

爲了建立一個用於描述Web服務的XML格式化文件，Web服務描述語言(WSDL)標準提供了足夠多的細節，以便可以構建出客戶端代碼，從而訪問服務或者服務器端代碼以提供服務。一個服務的WSDL文件將會爲你提供如下幾個方面的內容：

1. 用於訪問服務的地址信息
2. 用於傳送信息的傳輸協議(例如，通道數)
3. 用於全部可以使用功能的名稱和接口使用方法
4. 在全部的請求和響應中所使用的數據類型

2001 年3月，W3C推出了WSDL 1.1版本用於討論，這並非最終肯定的規範。W3C Web服務描述工做組目前正在開發該規範的2.0版本，基本上已經到了尾聲。雖然，WSDL一般是用於特定的SOAP服務，可是，從理論說，它是徹底能夠 用於特定的REST風格的GET或者POST操做的。

可以根據服務的WSDL描述來自動建立客戶端和服務器端代碼，支持這一功能的開發環境目前使用得很普遍，以便可以適用於Web服務器和Web服務客戶端的 不一樣程序設計語言。若是你使用Google搜索「SOAP IDE」的話，大概會出現上百萬條相關信息。也有這樣的工具，根據Java或C#對象來生成相應的WSDL和代碼。自動生成代碼也許可以使你的開發效率更 高，可是離優化倒是愈來愈遠。

 

SOAP數據包結構解析

SOAP的消息被稱爲一個SOAP Envelope，包括SOAP Header和SOAP Body。其中，SOAP Header能夠方便的插入各類其它消息來擴充Web Service的功能，好比Security（採用證書訪問Web Service），SOAP Body則是具體的消息正文，也就是Marshall後的信息。

SOAP調用的時候，也就是向一個URL（好比 http://api.google.com/search/beta2 ）發送HTTP Post報文（根據SOAP規範，HTTP Get報文也可被支持），調用方法的名字在HTTP Request Header SOAP-Action中給出，接下來就是SOAP Envelope了。服務端接到請求，執行計算，將返回結果Marshall成XML，用HTTP返回給客戶端。

 

 

4.REST

4.1.概念：

1. REST並非一種新興的技術語言，也不是什麼新的技術框架，非協議也非規範 。準確來講說REST只是一種概念、風格或者約束，是一種針對網絡應用的開發方式， 是迴歸HTTP自己的建議，能夠下降開發的複雜性，提升系統的可伸縮性。
2. REST是由Roy Thomas Fieding在他的博士論文《架構風格與基於網絡的軟件架構設計》中提出的一種架構思想。Roy Fielding是Apache基金會的合做創做者，同時也是HTTP、URI等Web基礎協議的主要設計者。從Roy Fielding的背景，我想你們就應該能瞭解到REST與Web之間的關係了吧。的確，在REST中咱們關注技術實際上也只是URI、HTTP、Hypertext（超文本）而已。
3. REST是中文翻譯爲表徵狀態轉移（英文：Representational State Transfer）是Roy Fielding博士在2000年他的博士論文中提出來的一種軟件架構風格。從字面意思來講，「表述」是很難理解是什麼東西的？從論文上咱們能夠看到表述，通常指HTML文檔（包括json，xml等），jpeg等圖片資源。
4. REST 採用Web 服務使用標準的 HTTP 方法 (GET/PUT/POST/DELETE) 將全部 Web 系統的服務抽象爲資源，REST從資源的角度來觀察整個網絡，分佈在各處的資源由URI肯定，而客戶端的應用經過URI來獲取資源的表徵。Http協議所抽象的get,post,put,delete就比如數據庫中最基本的增刪改查，而互聯網上的各類資源就比如數據庫中的記錄（可能這麼比喻不是很好），對於各類資源的操做最後老是能抽象成爲這四種基本操做，在定義了定位資源的規則之後，對於資源的操做經過標準的Http協議就能夠實現，開發者也會受益於這種輕量級的協議。
5. 談到REST你們的第一印象就是經過http協議的GET,POST,DELETE,PUT方法實現對url資源的CRUD（建立、讀取、更新和刪除）操做。這種形式的REST只是CRUD（增刪改查），從這個層面上，好像REST只是和RPC一個層面的東西，沒有什麼了不得，其實這些都是對REST誤讀。也誤導你們實現REST時，特種注重GET,POST,PUT,DELETE方法的處理，包括一些所謂的REST框架，好比JBoss RESTEasy，Restlet Tomcat。究其緣由是， REST提供了一組架構約束，看成爲一個總體來應用時，強調組件交互的可伸縮性、接口的通用性、組件的獨立部署、以及用來減小交互延遲、加強安全性、封裝遺留系統的中間組件。其實從整個REST推導過程當中能夠了解到，REST沒有說起HTTP協議的任何方法，只是後期你們從REST的統一接口中擴展出這些操做概念。

 

4.1.推導REST

先從理論層次上咱們看一下REST是怎麼推導來的（參考論文第五章）

         Web架構背後的設計基本原理，可以被描述爲由一組應用於架構中元素之上的約束組成的架構風格。當將每一個約束添加到進化中的風格時，會產生一些影響。經過檢查這些影響，咱們就可以識別出Web的約束所致使的屬性。而後就可以應用額外的約束來造成一種新的架構風格，這種風格可以更好地反映出現代Web架構所期待的屬性。經過簡述REST做爲架構風格的推導過程，後面各節將會詳細描述組成REST風格的各類特定約束

     0.   從「空」風格開始。從架構的觀點來看，空風格描述了一個組件之間沒有明顯邊界的系統，這就是咱們描述REST的起點。

1. 客戶-服務器。客戶-服務器約束背後的原則是分離關注點。經過分離用戶接口和數據存儲這兩個關注點，咱們改善了用戶接口跨多個平臺的可移植性；同時經過簡化服務器組件，改善了系統的可伸縮性。
2. 無狀態。這個約束致使了可見性、可靠性和可伸縮性三個架構屬性，可是無狀態並非沒有缺點的，無狀態增長了在一系列請求中發送的重複數據（每次交互的開銷），可能會下降網絡性，正由於這個缺點，因此在REST風格中增長了緩存的考慮。
3.  緩存，添加緩存約束的好處在於，它們有可能部分或所有消除一些交互，從而經過減小一系列交互的平均延遲時間，來提升效率、可伸縮性和用戶可覺察的性能。可是緩存仍是有缺點的，若是緩存中陳舊的數據與將請求直接發送到服務器獲得的數據差異很大，那麼緩存會下降可靠性。注意這裏的緩存並非指MC，redis之類的緩存，而是在網絡代理中，好比proxy服務器上的緩存機制。
4. 統一接口。使REST架構風格區別於其餘基於網絡的架構風格的核心特徵是，它強調組件之間要有一個統一的接口，爲了得到統一的接口，須要有多個架構約束來指導組件的行爲。REST由四個接口約束來定義：資源的識別（identification ofresources）、經過表述對資源執行的操做、自描述的消息（self-descriptive messages）、以及做爲應用狀態引擎的超媒體相關因素REST和其餘概念關係。統一接口的雖然晦澀，可是它是REST風格核心特徵，也是前面咱們討論經過CURD方式操做資源的一種表現，也是咱們最容易接觸感覺到的一層，後面淘寶，微博，微信開放平臺的開放接口，其實就是咱們接觸這個平臺的統一接口，評價一個開發平臺是否REST的標準，也在於這個平臺的設計者對統一接口的理解。
5. 分層系統，分紅系統風格經過限制組件的行爲（即，每一個組件只能「看到」與其交互的緊鄰層），將架構分解爲若干等級的層。經過將組件對系統的知識限制在單一層內，爲整個系統的複雜性設置了邊界，而且提升了底層獨立性。分層系統增長了數據處理的開銷和延遲，所以下降了用戶可覺察的性能對於一個支持緩存約束的基於網絡的系統來講，能夠經過在中間層使用共享緩存所得到的好處來彌補這一缺點。正由於REST風格有這樣的缺點，纔會特地強調緩存的做用。
6. 按需代碼，經過下載並執行applet形式或腳本形式的代碼，REST容許對客戶端的功能進行擴展，看似簡單的一種風格設計，其實對B/S貢獻最大的就是這個特性，如今ajax的底層其實就是按需代碼機制。

 

4.2.REST風格/約束：

Fielding 在他的論文中提出了一個RESTful應用應該具有的幾點約束。

1. 每一個資源都應該有一個惟一的標識
2. 使用標準的方法來更改資源的狀態
3. Request和Response的自描述
4. 資源多重表述
5. 無狀態的服務

Fielding 認爲，只有具有了上面的約束的應用才能算是REST應用，其實如今許多所謂的REST應用或服務，其實並不能算是真正的REST應用，目前不少所謂的REST應用，其實只是RPC而已。出現這樣的狀況很正常，由於RPC更符合通常程序員的思惟。

以後這幾個約束被表述爲：

1. Client–server C/S結構 (這是Internet服務的一個基本特徵)
2. 無狀態性
3. 可以利用Cache機制增進性能 (想起了瀏覽器?)
4. 分層系統 (想起了無數的架構?)
5. 統一的接口規範分層交互
6. 隨需代碼 - Javascript （可選，實際上是一種擴展性的要求)

 

看了這幾個特徵後,你想起了什麼? 你可能會破口而出：HTTP

HTTP是WWW的最核心的協議, 它將簡單的分佈於世界各個角落的資源都統一塊兒來, 統一的地址, 簡單的方法, 和必定數量的表達方式.(你可能對這三點描述很模糊,請go ahead).

REST 的三個要素就是是 惟一的資源標識, 簡單的方法 (此處的方法是個抽象的概念), 必定的表達方式.

REST 是以 資源 爲中心, 名詞即資源的地址, 動詞即施加於名詞上的一些有限操做, 表達是對各類資源形態的抽象.

以HTTP爲例，名詞即爲URI(統一資源標識), 動詞包括POST, GET, PUT, DELETE等(還有其它不經常使用的2個,因此 整個動詞集合是有限的), 資源的形態(如text, html, image, pdf等)

 

根據以上的描述，咱們其實發現HTTP是一種典型的REST風格，這也難怪，在1994年提出REST風格時，REST被稱做「HTTP對象模型」，可是那個名稱經常引發誤解，令人們誤覺得它是一個HTTP服務器的實現模型。這個名稱「表述性狀態轉移」是有意喚起人們對於一個良好設計的Web應用如何運轉的印象。反過來看HTTP就是REST的具體實現。在一個REST風格中，咱們可以感覺到的就是統一接口的數據，這些數據包括因此，當咱們開發一個web服務時，好比一個網站，因爲使用了HTTP(HTTPS)協議，其實就是一種REST風格，可是在這個REST風格中咱們着重處理的是兩點

       1：URI，即所謂的資源，網站的uri設計

       2：統一接口，即所謂的PUT,GET,POST,DELETE方法

雖然咱們的網站是REST的風格的，可是因爲統一接口設計的很差，致使咱們網站在訪問請求時，效率低下，以及可擴展性差。在深刻淺出REST中，做者總結了五條關鍵原

        1：爲全部「事物」定義ID

        2：將全部事物連接在一塊兒

        3：使用標準方法

        4：資源多重表述

        5：無狀態通訊

其中前四條就是對統一接口中的數據元素，第一二條講的就是uri，第三四條講的是控制數據。第五條無狀態通訊，這個須要特別說明下，無狀態通訊是指服務器和客戶端通訊是無狀態的，假如咱們的系統中使用Session保存客戶端狀態，這種狀況就是非無狀態通訊，是一種unREST的方式。可是應用自己是有狀態的，好比用戶登陸先後，就是應用狀態的變化。

 

 

4.3.REST與WEB

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

Fielding認爲，對於使用HTTP承載應用程序協議穿越防火牆，XML-RPC 和SOAP所採用的方式是「從根本上被誤導的概念。」它們所採用的方式違背了設立防火牆的概念，結果是，防火牆廠商爲了保護系統須要偵察出所承載的協議。因爲大多數SOAP應用程序使用HTTP都是爲了穿越防火牆，所以，你能夠發現REST與SOAP之間的衝突是從哪裏開始的。Fielding認爲，若是你打算使用HTTP的話，就應該與充分利用HTTP自己的含義。

REST風格強調，經過有限的操做或者是「動詞」以及一個組件之間的標準接口，也就是HTTP協議提供的藉口，來提高客戶與服務之間的交互。經過爲每個資源分配其本身的URL，來實現靈活性，REST能夠調用包含上百個URI的資源類型的客戶，其中的關鍵是REST可以給你無限多的「名詞」。REST使用HTTP的動詞——簡單的良定義操做集:POST, GET, PUT,DELETE進行請求和響應，從而避免了歧義。舉個例子，GET只可以簡單地返回資源的表現形式，而不可以建立任何其餘的內容。

在Web發展的初期，因爲人們都在試驗經過收集各類不一樣來源的元素，從而把Web應用程序融合在一塊兒，有大量這種Web服務的不成熟探索的例子——從HTTP頁面中解析信息，用於頁面建立者沒有計劃到的用途。這種「屏幕抓取」的Web類比代表，REST風格的方法是先於那些更加複雜的Web服務而出現的。

 

4.4.規劃REST服務

在InfoQ上有一篇很好的文章來介紹如何規劃REST服務《如何獲取（GET）一杯咖啡——星巴克REST案例分析》，估計你們看完這篇文章，應該對如何規劃REST服務會有更深的認識。

當咱們要規劃REST服務的時候，其中最關鍵的概念是「資源」。

資源是什麼呢？廣義上講，任何事物只要有用，它就是資源。狹義的講（在Web環境中），它是一個能夠存放、鏈接在計算機上，能夠經過比特流進行操控的實體。一個實體若要成爲資源，它必須有一個URI。在這裏URI包含了兩重含義：1)它是該資源的名稱 2)它是該資源的地址。

在規劃URI的時候，有幾點但願你們可以注意一下：

1. 一個URI標識一個資源，可是一個資源能夠被多個URI標識。
2. 資源也是有層次的，這個層次應該在URI上充分的體現出來。
3. 在規劃URI的時候，須要定義一些團隊內部確認的關鍵字或符號，這些關鍵字或符號是有特殊意義的，不能隨便使用。
4. 須要有一個URI定義的文檔，以備之後的查詢和維護。
5. 能夠使用URI Template來描述URI的定義。如何使用URI Template請看看這篇文章。

當咱們定義好資源以後，接下來要作的事情就是定義操做資源的方法以及資源的表述格式了。

使用HTTP提供的基本方法來對資源進行操做，通常的操做定義以下：POST（建立資源）、GET（獲取資源）、PUT（修改資源）、DELETE（刪除）。它們正好對應了CRUD。

對資源的表述，通常的選擇會是XML，可是我更加推薦使用JSON來表述資源。在網絡中的傳輸量小，並且也便於JavaScript解析，同時使用其餘語言解析也是很是方便的事情。不過，最關鍵的仍是佔用更少的資源，讓一樣的資源可以服務於更多的人。

 

 

4.5.一個簡單的REST舉例

　　假設咱們但願一個Web服務暴露一部分目錄，從這個目錄中，用戶將可以獲得一些描述、圖片、安裝指令等等。爲了獲得數字「n1996-01」的描述，用戶須要格式化一個GET請求，相似於下面的這個URL： http://company.com/catalog/description/n1996-01

　　在處理這個請求時，「/catalog」將映射到一個服務中，以後，經過該服務對「description/n1996-01」進行解釋，從而 定位資源。在建立響應時，服務須要使用內容類型(Content-Type)的頭文件來指定返回格式。在這種狀況下，假定返回格式是HTML或者XML， 客戶端可以使用它來控制頁面的佈局。若是要獲得圖片，那麼這個請求將對「/catalog/picture/n1996-01」進行尋址，返回的響應將是 圖片內容類型(Content-Type)。

 

 

4.6.REST的應用場景：

其實，咱們常常容易犯的一個錯誤是：當咱們瞭解了一個新的技術，就會用這個技術來解決全部的問題。有一句諺語是這麼來講的：「在錘子的眼裏，全部的東西都是釘子」，其實REST也只是咱們工具箱裏面的其中的一個工具而已，但願不要把它當作咱們惟一的工具。下面，咱們就來聊聊適合使用REST的應用場景和不適合使用REST的應用場景。

在我看來，REST最適合的應用場景是須要對外暴露服務的狀況。此時，咱們能夠充分利用REST的自描述、無狀態、惟一標識等特性來提供清晰、友好的API；此外，目前Jesery、RESTEasy等JAX-RS框架也提供了OAuth的支持，基本上可以保證服務安全。

最不適合的應用場景是對性能要求高的系統內部的服務調用，在這種狀況下使用REST的話，那麼REST全部的特性都會變成拖累。這個時候，仍是須要選擇更底層的通訊協議和方式會更好一些，好比ICE。這樣的錯誤，我曾經犯過，後來經過很長時間的努力才慢慢的將這個錯誤改過來。

 

4.7.RPC與REST的比較

1. RPC是以動詞爲中心的，REST是以名詞爲中心的，此處的動詞指的是一些方法，名詞是指資源。REST強調資源(名詞)有統一的接口以此來對它們尋址，而RPC強調過程(動詞)有統一的接口來激發它們
   1. 你會發現,以動詞爲中心,意味着,當你要須要加入新功能時,你必需要添加更多的動詞, 這時候服務器端須要實現 相應的動詞(方法), 客戶端須要知道這個新的動詞並進行調用.
   2. 而以名詞爲中心, 假使我請求的是 hostname/friends/, 不管這個URI對應的服務怎麼變化,客戶端是無需 關注和更新的,而這種變化對客戶端也是透明的.
   3. 一個基於RPC的架構，動詞數量是 沒有限制的。REST說，咱們使用四個動詞——很是熟悉，HTTP標準的GET、POST、PUT以及DELETE——來進行請求和響應，REST使用資 源尋址來處理其可變性
2. 至於其它的區別,如對實現語言的依賴, 耦合性等,這些都是上面提到的這個根本區別所衍生的
3. REST迴歸HTTP最初的設計；RPC僅僅只是把HTTP做爲傳輸協議來使用。
4. REST是由超文本驅動的；RPC是由方法驅動的。
5. REST強調HTTP通訊的語義可見性，經過消息頭和標準的HTTP方法來體現；RPC把語義封裝在HTTP消息體中。

如何選擇?

根據筆者本身的經驗和心得, 建議 可以使用REST就儘可能使用REST, 主要基於下面幾個考慮:

1. 擴展性
2. 鬆耦合(意味着,不用強制要求客戶端去更新相應的代碼)
3. 客戶端實現語言無關
4. 性能
5. 安全性(例如HTTPS)

固然上述的幾點也並不是 RPC 都不知足,不過相對而言, REST 更加清晰和簡潔, 再輔以 JSON 相應的服務會在性能和穩定性(簡單一般意味着robust)方面有很大的提升.

 

整體上，由於REST模式的Web服務與複雜的SOAP和XML-RPC對比來說明顯的更加簡潔，愈來愈多的web服務開始採用REST風格設計和實現。例如，Amazon.com提供接近REST風格的Web服務進行圖書查找；雅虎提供的Web服務也是REST風格的。REST對於資源型服務接口來講很合適，同時特別適合對於效率要求很高，可是對於安全要求不高的場景。而SOAP的成熟性能夠給須要提供給多開發語言的，對於安全性要求較高的接口設計帶來便利。因此我以爲純粹說什麼設計模式將會佔據主導地位沒有什麼意義，關鍵仍是看應用場景，正是那句老話：適合的纔是最好的

同時很重要一點就是不要扭曲了REST如今不少網站都跟風去開發REST風格的接口，其實都是在學其形，不知其心，最後弄得不三不四，性能上不去，安全又保證不了，徒有一個看似象摸象樣的皮囊。

 

4.8.soap與REST比較：

1. REST依賴一套簡單的「動詞」，把全部的複雜性都轉移到了指定資源的「名詞」中。與此不一樣，SOAP卻有一套至關複雜的XML格式化命令和數據傳輸選項。
2. 很是重要一點是，REST是須要請求HTTP的，與其相比，SOAP更具優點，SOAP消息能夠由全部可以處理Unicode文本的傳輸方式來傳 送，很惋惜，這一點一般不被人們所承認。事實是，因爲HTTP穿透防火牆的便捷性，以及開發商們對Web很是熟悉，所以，人們還在繼續強調着HTTP傳 輸。
3. 在 開發人員的意識裏，對於Web服務的開發而言，REST和SOAP風格各有千秋。SOAP擁有更爲詳盡的標準化成果和開源工具。除此以外，如今，有許多 集成開發環境可以在現有代碼的基礎上，依據接口方法自動生成SOAP。若是你須要使用WSDL來發布你的服務，或者你須要一些安全功能如消息簽名和加密， 那麼，SOAP可以確保消息的安全性。另外一方面，若是你但願使用簡單接口來公佈一些信息，而不須要繁瑣的處理過程，那麼，REST也許是最佳選擇。
4. 衆多從事Web服務的軟件設計師們認爲SOAP過分複雜，因而，相似eBay和Google的服務都採用了REST風格的約束來暴露其大量數據。
5. 甚至能夠有RESTful SOAP。儘管還網上沒人提到RESTful SOAP，但我以爲這在理論上是沒問題的

形成SOAP和REST放在一塊兒討論是由於，網絡上不少工程師把REST風格和REST的實現混淆了。REST的概念比較寬泛，自己若是符合1)Client–server, 2)Stateless, 3)Cacheable, 4)Layered system, 和5)Uniform interface這幾個主要的限制，就是RESTful的設計。同時呢，因爲HTTP是一個很容易知足stateless, cacheable，uniform interface的protocol,因此實際上REST被默認就是用HTTP來實現，不少人耳熟能詳HTTP的verb如何對應到resource的CRUD，彷彿也成了REST風格自己的死規定。我認爲其實否則，以HTTP中的PUT爲例，若是用PUT來實現resource的update,那麼就必需要保證idempotent，每次傳給server的信息，必須是resource的所有信息，不能做partial update。不難發現，用PUT來實現update，實際上是在REST的constraint上又加上了HTTP的一些限制。若是咱們放棄PUT的constraint，採用POST來實現update，則partial update是能夠的。緊接着就由一個問題，既然PUT被POST替代，那麼咱們是否能夠用POST來代替GET和DELETE呢？筆者認爲應該沒問題，一個很現實的例子，若是browser不支持DELETE，用POST來work around是很常見的。

okay, 再來看看SOAP，不少在HTTP上實現的SOAP協議就是用POST來實現的 (wikipedia裏SOAP的一個sample http://en.wikipedia.org/wiki/SOAP#Example_message)

所以，當咱們使用HTTP POST來實現REST，再加上XML的數據傳輸格式，其實咱們就是在SOAP上面實現了RESTFul的"風格"(儘管還網上沒人提到RESTful SOAP，但我以爲這在理論上是沒問題的)。

與RESTful SOAP相對的一個例子，不少基於Rails的website（並不是說Rails很差，Rails大行其道使得REST風行，故舉例）URL風格是/callSomeMethodWithArgumentA, /callSomeMethodWithArgumentB，很是長，不uniform，不知足REST的限制，這些route都是不RESTFul的，咱們能夠稱之爲non-RESTful HTTP

長話短說，本人認爲SOAP協議和REST架構風格是兼容的。雖然，約定俗成，REST的具體實現通常採用HTTP，且充分利用HTTP verb的不一樣特性，從而造成了一些約定俗稱的範式，但這種實現自己不是REST"風格"的核心。

 

目前，大部分Web開發者彷佛都瞭解REST——一種採用標準URI進行調用的方案。REST很容易理解，並且只要是支持HTTP/HTTPS的客戶端/服務器就支持它。你能夠用HTTP GET方法來執行命令。因此，開發者們感覺到的REST的優點是：開發簡單、只需依託現有Web基礎設施、以及學習成本低。

然而，SOAP做爲一種古老的Web服務技術，短時間內還不會退出歷史舞臺。並且，隨着SOAP 1.2的出現，SOAP印象中的一些缺點已獲得改進，採納率和易用程度也都獲得提升。另需注意的是，從W3C SOAP 1.2版開始，SOAP這一縮寫再也不表明Simple Object Access Protocol（簡單對象訪問協議），而是僅僅做爲協議名稱而已。

相對REST而言，SOAP 1.2多出一些開銷，不過這些開銷也帶來了一些好處。首先，SOAP在三個方面離不開XML（Extensible Markup Language，可擴展標記語言）：SOAP信封（envelope）是基於XML的，它定義了消息裏有什麼以及如何處理它；一套用於數據類型的編碼規則；過程調用和響應的規劃。SOAP信封由傳輸協議（HTTP/HTTPS）發出，RPC（Remote Procedure Call，遠程過程調用）獲得執行，而後一個XML文檔隨SOAP信封返回。

須要注意的是，基於「通用」傳輸協議是SOAP的一個優勢。REST目前基於HTTP/HTTPS；而SOAP可支持任何傳輸協議，從HTTP/HTTPS到SMTP（Simple Mail Transfer Protocol，簡單郵件傳送協議），甚至JMS（Java Messaging Service，Java消息傳遞服務）。不過，因爲XML較爲冗長且解析費時，所以採用XML也成爲一個弊端。

不過，對Web開發者來講的好消息是，目前上述兩種方案都是行之有效的方案。REST和SOAP都能解決許多Web方面的問題與挑戰，並且在許多狀況下，它們各自都能知足開發者的要求，也就是說可互換使用。

但不少人不知道，這兩種技術能夠混合搭配使用。REST很好理解，且極易上手；不過因爲它缺少標準，所以只被看做是一種架構方法。與之相比，SOAP是一個工業標準，它具有良好定義的協議，以及一套良好確立的規則，在大型和小型系統中均有采用。

所以，REST的適用場合包括：

有限的帶寬和資源 別忘了返回的結構能夠採用（由開發者定義的）任何格式。另外，因爲REST採用標準的GET、PUT、POST和DELETE動詞，所以可被任何瀏覽器所支持。除此之外，REST還能夠使用爲目前大多數瀏覽器支持的XMLHttpRequest對象，這爲AJAX增色很多。

徹底無狀態的操做 對於那些需多步執行的操做，REST並不是最佳選擇，採用SOAP更合適。可是，若是你須要無狀態的CRUD（Create/Read/Update/Delete，建立/讀取/更新/刪除）操做，那麼應採用REST。

緩存考慮 若要利用無狀態操做的特性，使得信息可被緩存，那麼REST是很好的選擇。

以上已經覆蓋不少方案了，那麼，爲何還要考慮SOAP呢？正如前述，SOAP比較成熟並且是通過良好定義的，具備完整的規範。而REST只不過是一種方法，對開發未做任何規約；所以，假如你遇到如下場合，那麼SOAP是最佳選擇：

異步處理與調用 若是你的應用須要確保可靠性與安全性，那麼請採用SOAP。SOAP 1.2爲確保這種操做補充定義了WSRM（WS-Reliable Messaging）等標準。

形式化契約 若提供者/消費者雙方必須就交換格式取得一致，那麼採用SOAP更合適。SOAP 1.2爲這種交互提供了嚴格的規範。

有狀態的操做 若是應用須要上下文信息與對話狀態管理，那麼應採用SOAP。SOAP 1.2爲此補充定義了WS-Security、WS-Transactions和WS-Coordination等標準。相比之下，REST方法要求開發者本身來實現這些框架性工做。

正如你所看到的，REST和SOAP各自有其用武之地。它們在安全性和傳輸層等方面有着本身的潛在問題，不過它們都能完成任務，並且在許多狀況下，它們都豐富了Web的技術手段。所以，就這一論題，其實最好的原則就是靈活性原則；由於至少在現今的Web開發中，不管面對何種問題，Web開發者們總有辦法運用好這兩種技術中的一種。