webservice restful rpc

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.