REST vs Web Service

webservice:

上世紀90年代流行的分布式技術，如DCOM,CORBA,RMI，範式是RPC，但各系統資料類型不一緻，實作/調用機制不同，各系統間互通不可能。XML的出現，讓資料類型一緻了，SOAP的出現，讓各系統可以互相調用了。Simple Object Access Protocol的原意是XML-RPC，但人們很快就發現方法調用太狹隘，而消息傳遞更加通用。WSDL即支援rpc/encoded也支援document/literal，但前者已成為曆史遺留。

webservices是soa的道成肉身，rpc方式的webservices是曆史遺留。

rest是roa的道成肉身。（這方面我不熟悉）

RMI CORBA DCOM

XML-rpc soap wsdl

微軟的DCOM，sun的RMI、JMS，和OMG的CORBA

RMI：Romote Method  Invocation，遠端方法調用。基于java遠端消息交換協定JRMP通信；JRMP是專為java遠端對象制定的協定。是分布式應用程式的100%java解決方法。RMI對非java語言應用程式支援不足，不能實作互通。

RMI是面向對象的程式設計模型。廣泛應用與EJB架構系統中。

RMI基于調用的模式，調用過程如下：用戶端程式調用服務對象的用戶端代理，代理負責打包參數并通過JRMP協定發送到服務端，服務端使用同樣協定解析，執行業務邏輯處理，用同樣方法傳回結果給用戶端。

RPC：RPC算是這幾類的統稱（這樣說有點不準确，但也可以這麼了解）。  RPC（Remote Procedure Call）遠端過程調用，是實作分布式計算的一種技術。在某種傳輸協定（TCP\HTTP等)上攜帶資訊資料，通過網絡從遠端計算機程式上請求服務。在OSI模型中，RPC跨越了傳輸層和應用層，使開發網絡分布式應用程式變得容易。用戶端代碼像調用本地方法一樣調用遠端方法。

RPC基于請求應答模式，用戶端發送調用資訊（将遠端方法名、參數打包進請求資訊）到服務端，服務端解析到要調用的對象和方法執行後傳回應答資訊；用戶端接受相應擷取應答資訊。

        RPC是跨語言的通信标準，sun和微軟都有其實作,微軟的DCOM就是建立在ORPC協定之上。

RPC是面向過程的程式設計模型。

XML-RPC:XML Remote Procedure Call，即XML遠端方法調用,利用http+xml封裝進行RPC調用。基于http協定傳輸、XML作為資訊編碼格式。一個xml-rpc消息就是一個請求體為xml的http-post請求，服務端執行後也以xml格式編碼傳回。這個标準面前已經演變為下面的SOAP協定。可以了解SOAP是XML-RPC的進階版本。

SOAP:Simple Object Access Protocol ,簡單對象通路協定，是一種輕量的、簡單的、基于xml的遠端通路協定。可以與現有的多種傳輸層或應用層協定結合使用，如TCP、HTTP、SMTP等。SOAP廣泛使用的是基于HTTP和xml協定的實作（SOAP=RPC+HTTP+XML），也就是大家常提的Web Service使用的通信協定。一個SOAP方法可以簡單地看作遵循SOAP編碼規則的HTTP請求和響應。

比較：XML－RPC是啟動web服務最容易的方法，在很多方面比SOAP更簡單易用，但不同于SOAP的是，XML－RPC沒有相應的服務描述文法，這妨礙了XML－RPC服務的自動調用。

JSON-RPC:JSON Remote Procedure Call，即JSON遠端方法調用 。類似于XML-RPC，不同之處是使用JSON作為資訊交換格式。

REST:

Some ‘RESTful’ APIs are really just RPC over HTTP

The REST architecture reuses the world wide web infrustructure where possible

XML

JSON: JavaScript Object Notation

Ajax:

HTTP:GET, POST, PUT, DELETE

URL:

XML-RPC: XML Remote Procedure Call

這種遠端過程調用使用http作為傳輸協定，XML作為傳送資訊的編碼格式。Xml-Rpc的定義盡可能的保持了簡單，但同時能夠傳送、處理、傳回複雜的資料結構。

XML-RPC是工作在Internet上的遠端過程調用協定。一個XML-RPC消息就是一個請求體為xml的http-post請求，被調用的方法在伺服器端執行并将執行結果以xml格式編碼後傳回。

在RMI和RPC之間最主要的差別在于方法是如何被調用的。在RMI中，遠端接口使每個遠端方法都具有方法簽名。如果一個方法在伺服器上執行，但是沒有相比對的簽名被添加到這個遠端接口上，那麼這個新方法就不能被RMI客戶方所調用。

簡單描述:

rpcclient的工作原理:rpcclient根據URL找到rpcserver -> 構造指令包，調用rpcserver上的某個服務的某個方法 -> 接收到rpcserver的傳回,解析響應包，拿出調用的傳回結果。

rpcserver的工作原理:啟動一個webserver(在使用内置的webserver的情況下) -> 注冊每個能提供的服務，每個服務對應一個Handler類 ->進入服務監聽狀态。

1. 曆史

第一輪：HTTP，帶來了Internet與電子商務

第二輪：Java，cross-platform，最早的RMI

第三輪：XML，标準的資料封裝技術，各種App之間交換資料不再是難事。

第四輪：RPC，Webservice、REST、高性能通信協定

2. What is RPC？

簡單了解: 可互操作的Web服務

RPC（Remote Procedure Call）

–    在某種傳輸協定（TCP\HTTP等)上攜帶資訊資料，通過網絡從遠端計算機程式上請求服務

–    在OSI模型中，RPC跨越了傳輸層和應用層

–    基于請求應答模式

–    跨語言的通信标準

任何一個RPC規範和實作都包含:

–    服務層（service）：RPC接口定義與實作

–    協定層（protocol）：RPC封包格式和資料編碼格式

–    傳輸層（transport）：實作底層的通信（如 socket）

應用程式通信性能比較：ipc<tcp<http<soap

3. RPC

以XML-RPC為代表介紹

XML-RPC（XML Remote Procedure Call）

    – 協定層：XML

    – 傳輸層：HTTP（許多防火牆也配置為隻允許HTTP連接配接）

一個XML-RPC消息就是一個請求體為xml的http-post請求，服務端執行後也以xml格式編碼傳回。

4. webservice

Webservice平台是一套标準，它定義了應用程式如何在Web上實作互操作性。标準包括：

    – 描述資料的方法：XML

    – 資訊交換的協定：SOAP

    – 傳輸協定：HTTP

    – Web服務描述語言：WSDL

    – 釋出注冊：UDDI

    – 服務具體的實作技術：Java，C，Ptyhon…

SOAP介紹

–    可以看做是XML-RPC的進階版本

–    SOAP是一種輕量的、簡單的、基于XML的協定，允許應用程式通過HTTP來交換資訊。或者更簡單地講，SOAP是用于通路Web服務的協定。

–    一個SOAP請求實際上也是一個http-post請求

更多了解參考"Webservice/SOAP/WSDL釋疑篇"

5. REST

REST介紹

–    具象狀态傳輸（Representational State Transfer）

–    業界開放服務新标準

–    面向資源開開發

–    公開目錄結構式的 URI（http://twitter.com/statuses/user/zhangxu）

–    回歸HTTP協定本性（GET、POST、PUT、DELETE）

6. 高性能應用程式通信協定

傳統的RPC

    – 不管是json還是xml傳輸資料，效率很低

RMI

    – 效率高，僅适用于Java

直接socket連接配接

    – 需要開發自己的協定，成本高

是以需要通過二進制HTTP傳輸的高性能通信中間件，其中高性能可以了解為：

–    對象的序列化、反序列化高性能

–    壓縮算法高性能

–    傳輸高性能

常用于企業内部系統間的互動

常用技術

–    hessian、thrift、protocol buffer

6.1 Hessian

Hessian 是開源的遠端通訊協定。 Hessian 采用二進制 RPC 協定，基于 HTTP 傳輸，伺服器端不用開放防火牆端口。 Hessian 協定的規範是公開的，可以用于任意語言。

Hessian通常通過Web應用來提供服務，是以非常類似于WebService。它不使用SOAP協定，并且按照二進制傳輸。

一次調用的流程：

    用戶端——>序列化寫到輸出流——>遠端方法（伺服器端）——>序列化寫到輸出流 ——>用戶端讀取輸入流——>輸出結果

6.2 Thrift

參考文章“跨平台通信中間件thrift學習【Java版本】”

6.3 protobuf

protocol buffer 是 google 的一種資料交換的格式，它獨立于語言，獨立于平台。google 提供了多種語言的實作：java、c++ 和 python等，每一種實作都包含了相應語言的編譯器以及庫檔案。由于它是一種二進制的格式，比使用 xml 進行資料交換快許多。可以把它用于分布式應用之間的資料通信或者異構環境下的資料交換。

Protobuf隻有一種序列化和反序列化的手段，并不涉及傳輸層

Protobuf序列化效率業界最高！

什麼是Rest？

     rest，即REST(Representational State Transfer 表述性狀态轉移)是一種針對網絡應用的設計和開發方式，可以降低開發的複雜性，提高系統的可伸縮性。

     REST特點：

     1. Rest是一種設計風格，不是一個标準。

     2. Rest通常使用HTTP,URI，XML，HTML等流行的協定和标準

     3. Rest是從資源的角度來觀察網絡的，而資源是由URI來指定的。

     4. Rest對資源的操作類型通常包括：擷取，建立，删除和修改，這四種操作分别對應着HTTP協定請求的GET,POST,DELETE和PUT方法。

     5. 資源的表現形式可以為:XML,HTML,JSON的文本。

     6. Rest是服務端-用戶端結構中的一種應用方法。

     7. Rest使用的是HTTP協定，是以是無狀态的。

     接下來，我們來了解下為什麼要Rest？要弄清楚這個問題首先要了解一下計算機軟體之間通訊技術的發展曆程。在計算機通訊中，TCP/IP協定是最為通用的标準協定，TCP是傳輸控制協定，IP是網際協定，但這兩種協定都是非常原始的（RAW）,TCP協定是傳輸層協定，而IP是網絡層協定。通過TCP/IP的确能勝任将資訊從一個計算機傳遞給另外一台。但大家都知道比較底層的東西，往往比較難于了解。是以一些應用層協定營運而生，最初的應用層協定有SMTP,POP3,FTP,HTTP等，時至今日，大家每天使用最多的仍然是這些老牌應用協定。但這些協定同時都是有應用條件的。

RMI(remote method invocation，面向對象的遠端方法調用)

RPC（remote procedure call，遠端過程調用）

SOAP(simple object access protoal，簡單對象通路協定)

REST(representational state transfer，表達性狀态轉移)

以上都了解為調用遠端方法的一些通信技術“風格”。

1.Tcp/Ip （socket，RMI）

     早些時候，程式員們為了讓兩個應用程式之間能夠通訊，通常采用的是使用Socket的開發的TCP/IP通訊程式，并且都是自己定義資料格式規範，這種模式的優點是個性化，通常效率較高，但同時因為都各自為政，往往是開發了好多種程式，但每種都不一樣，這對于愛偷懶的程式員來講，真是杯具了呀！

     RMI就好比它是本地工作，采用tcp/ip協定，用戶端直接調用服務端上的一些方法。優點是強類型，編譯期可檢查錯誤，缺點是隻能基于JAVA語言，客戶機與伺服器緊耦合。

2.RPC

     一些程式員開始想到，如果調用遠端的一個方法能夠像調用本地方法一樣，那就簡化多了，于是RPC模式的通訊産生了. RPC使用C/S方式，采用http協定，發送請求到伺服器，等待伺服器傳回結果。這個請求包括一個參數集和一個文本集，通常形成“classname.methodname”形式。優點是跨語言跨平台，C端、S端有更大的獨立性，缺點是不支援對象，無法在編譯器檢查錯誤，隻能在運作期檢查。

3.SOAP

     之後為了标準化，跨平台又産生了基于SOAP協定的消息通訊模型。SOAP是在XML-RPC基礎上，使用标準的XML描述了RPC的請求資訊（URI/類/方法/參數/傳回值）。因為XML-RPC隻能使用有限的資料類型種類和一些簡單的資料結構，SOAP能支援更多的類型和資料結構。優點是跨語言，非常适合異步通信和針對松耦合的C/S，缺點是必須做很多運作時檢查。

4.REST

     但随着時間的推移和SOAP的推廣情況，大家很快發現，其實世界上已經存在了一個最為開放，最為通用的應用協定，那就是HTTP，使用SOAP的确讓程序間通訊變得簡單易用，但并不是每個廠商都願意将自己的老系統再更新為支援SOAP，而且SOAP的解析也并不是每種語言都内置支援，比如JS.而HTTP正好完美了解決了這個問題，那好吧，我們就設計一種使用HTTP協定來完成服務端-用戶端通訊的方法吧，Rest應運而生。

     REST一般用來和SOAP做比較，它采用簡單的URL方式來代替一個對象，優點是輕量，可讀性較好，不需要其他類庫支援，缺點是URL可能會很長，不容易解析。

總結來說，計算機通訊的曆程可以用下圖來闡述：

REST與RPC風格之比較

     RPC(遠端過程調用)的架構，是應用在基于XML-RPC(或者 RPC風格)的SOAP的Web服務中的。用戶端發出指令，以使服務做出特定的操作。換句話說，RPC有動詞的傾向。

     REST強調資源(名詞)有統一的接口以此來對它們尋址，而RPC強調過程(動詞)有統一的接口來激發它們。一個基于RPC的架構，動詞數量是沒有限制的。REST說，我們使用四個動詞——非常熟悉，HTTP标準的GET、POST、PUT以及DELETE——來進行請求和響應，REST使用資源尋址來處理其可變性。

REST和SOAP風格之比較

     REST風格的Web服務依賴一套簡單的“動詞”，HTTP标準的GET、POST、PUT以及DELETE，把所有的複雜性都轉移到了指定資源的“名詞”中。與 REST 架構相比，SOAP 架構圖明顯不同的是：所有的 SOAP 消息發送都使用 HTTP POST 方法，并且所有 SOAP 消息的 URI 都是一樣的，這是基于 SOAP 的 Web 服務的基本實踐特征。

     在Web服務發展的初期，XML格式化消息的第一個主要用途是，應用于XML-RPC協定，其中RPC代表遠端過程調用。在XML遠端過程調用(XML-RPC)中，用戶端發送一條特定消息，該消息中必須包括名稱、運作服務的程式以及輸入參數。相反， REST風格的請求卻不關心正在運作的程式是什麼，它僅僅請求命名資源。

     XML-RPC隻能使用有限的資料類型種類和一些簡單的資料結構。人們認為這個協定還不夠強大，于是就出現了SOAP——其最初的定義是簡單對象通路協定。之後，大家逐漸意識到SOAP其實并不簡單，而且也不需要必須使用面向對象語言，是以，現在人們隻是沿用SOAP這個名稱而已。

     XML-RPC隻有簡單的資料類型集，取而代之，SOAP是通過利用XML Schema的不斷發展來定義資料類型的。同時，SOAP也能夠利用XML 命名空間，這是XML-RPC所不需要的。如此一來，SOAP消息的開頭部分就可以是任何類型的XML命名空間聲明，其代價是在系統之間增加了更多的複雜性和不相容性。

     另外，非常重要一點是，REST是需要請求HTTP的，與其相比，SOAP更具優勢，SOAP消息可以由所有能夠處理Unicode文本的傳輸方式來傳送，很可惜，這一點通常不被人們所認可。事實是，由于HTTP穿透防火牆的便捷性，以及開發商們對Web非常熟悉，是以，人們還在繼續強調着HTTP傳輸。

     随着計算機行業的覺醒，人們發現了基于XML的Web服務的商業潛力，于是，各家公司開始不斷地發掘想法、觀點、論據以及标準化嘗試。W3C曾經設法以“Web服務活動”的名義來組織成果展，其中也包括實際做出SOAP的XML協定工作組(XML Protocol Working Group)。與Web服務有關的标準化成果——從某種程度上說與SOAP相關或者依賴于SOAP——的數量已經倍增了到了令人驚訝的程度。

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

REST風格web service和SOAPweb service的選擇

以下從成熟度，效率和易用性，安全性三方面講如何選擇使用這兩種風格：

     成熟度(總的來說SOAP在成熟度上優于REST)

     SOAP雖然發展到現在已經脫離了初衷，但是對于異構環境服務釋出和調用，以及廠商的支援都已經達到了較為成熟的情況。不同平台，開發語言之間通過SOAP來互動的web service都能夠較好的互通（在部分複雜和特殊的參數和傳回對象解析上，協定沒有作很細緻的規定，導緻還是需要作部分修正）

     REST國外很多大網站都釋出了自己的開發API，很多都提供了SOAP和REST兩種Web Service，根據調查部分網站的REST風格的使用情況要高于SOAP。但是由于REST隻是一種基于Http協定實作資源操作的思想，是以各個網站的REST實作都自有一套，在後面會講訴各個大網站的REST API的風格。也正是因為這種各自實作的情況，在性能和可用性上會大大高于SOAP釋出的web service，但統一通用方面遠遠不及SOAP。由于這些大網站的SP往往專注于此網站的API開發，是以通用性要求不高。

     由于沒有類似于SOAP的權威性協定作為規範，REST實作的各種協定僅僅隻能算是私有協定，當然需要遵循REST的思想，但是這樣細節方面有太多沒有限制的地方。REST日後的發展所走向規範也會直接影響到這部分的設計是否能夠有很好的生命力。

     效率和易用性(REST更勝一籌)

     SOAP協定對于消息體和消息頭都有定義，同時消息頭的可擴充性為各種網際網路的标準提供了擴充的基礎，WS-*系列就是較為成功的規範。但是也由于SOAP由于各種需求不斷擴充其本身協定的内容，導緻在SOAP處理方面的性能有所下降。同時在易用性方面以及學習成本上也有所增加。

     REST被人們的重視，其實很大一方面也是因為其高效以及簡潔易用的特性。這種高效一方面源于其面向資源接口設計以及操作抽象簡化了開發者的不良設計，同時也最大限度的利用了Http最初的應用協定設計理念。同時，在我看來REST還有一個很吸引開發者的就是能夠很好的融合目前Web2.0的很多前端技術來提高開發效率。例如很多大型網站開放的REST風格的API都會有多種傳回形式，除了傳統的xml作為資料承載，還有（JSON,RSS,ATOM）等形式，這對很多網站前端開發人員來說就能夠很好的mashup各種資源資訊。

     安全性：

     這點其實可以放入到成熟度中，不過在目前的網際網路應用和平台開發設計過程中，安全已經被提到了很高的高度，特别是作為外部接口給第三方調用，安全性可能會高過業務邏輯本身。

     SOAP在安全方面是通過使用XML-Security和XML-Signature兩個規範組成了WS-Security來實作安全控制的，目前已經得到了各個廠商的支援，.net ，php ，java 都已經對其有了很好的支援（雖然在一些細節上還是有不相容的問題，但是互通基本上是可以的）。

     REST沒有任何規範對于安全方面作說明，同時現在開放REST風格API的網站主要分成兩種，一種是自定義了安全資訊封裝在消息中（其實這和SOAP沒有什麼差別），另外一種就是靠硬體SSL來保障,但是這隻能夠保證點到點的安全，如果是需要多點傳輸的話SSL就無能為力了。安全這塊其實也是一個很大的問題，今年在BEA峰會上看到有示範采用SAML2實作的網站間SSO，其實是直接采用了XML-Security和XML-Signature，效率看起來也不是很高。未來REST規範化和通用化過程中的安全是否也會采用這兩種規範，是未知的，但是加入的越多，REST失去它高效性的優勢越多。

     具體選擇舉例：

     在開發人員的意識裡，對于Web服務的開發而言，REST和SOAP風格各有千秋。SOAP擁有更為詳盡的标準化成果和開源工具。除此之外，現在，有許多內建開發環境能夠在現有代碼的基礎上，依據接口方法自動生成SOAP。如果你需要使用WSDL來釋出你的服務，或者你需要一些安全功能如消息簽名和加密，那麼，SOAP能夠確定消息的安全性。另一方面，如果你希望使用簡單接口來公布一些資訊，而不需要繁瑣的處理過程，那麼，REST也許是最佳選擇。

     假如我們要通訊的兩個應用程式都是同一個架構的，比如都是.Net Application，或者都是Java Application，或者二者是其他對SOAP支援較好的程式，那麼建議使用Soap形式來實作通訊，但如果服務的客戶有使用浏覽器調用服務，有使用js調用服務的需求，那麼最好服務最好還是設計成Rest風格的。也就是說現階段其實Rest的開放性，通用性都要優于SOAP.