關(guān)于 REST 介紹的文章已經(jīng)很多了，這里只對 RPC 部分做一個介紹：

RPC(遠程過程調(diào)用)是什么

簡單的說，RPC就是從一臺機器(客戶端)上通過參數(shù)傳遞的方式調(diào)用另一臺機器(服務器)上的一個函數(shù)或方法(可以統(tǒng)稱為服務)并得到返回的結(jié)果。

RPC 會隱藏底層的通訊細節(jié)(不需要直接處理Socket通訊或Http通訊)

RPC 是一個請求響應模型。客戶端發(fā)起請求，服務器返回響應(類似于Http的工作方式)

RPC 在使用形式上像調(diào)用本地函數(shù)(或方法)一樣去調(diào)用遠程的函數(shù)(或方法)。

遠程過程調(diào)用發(fā)展歷程

ONC RPC (開放網(wǎng)絡計算的遠程過程調(diào)用)，OSF RPC(開放軟件基金會的遠程過程調(diào)用)

CORBA(Common Object Request Broker Architecture公共對象請求代理體系結(jié)構(gòu))

DCOM(分布式組件對象模型)，COM+

Java RMI

.NET Remoting

XML-RPC，SOAP，Web Service

PHPRPC，Hessian，JSON-RPC

Microsoft WCF，WebAPI

ZeroC Ice，Thrift，GRPC

Hprose

早期的 RPC

第一代 RPC(ONC RPC，OSF RPC)不支持對象的傳遞。

CORBA 太復雜，各種不同實現(xiàn)不兼容，一般程序員也玩不轉(zhuǎn)。

DCOM，COM+ 逃不出 Windows 的手掌心。

RMI 只能在 Java 里面玩。

.NET Remoting 只能在 .NET 平臺上玩。

XML-RPC，SOAP，WebService

冗余數(shù)據(jù)太多，處理速度太慢。

RPC 風格的 Web Service 跨語言性不佳，而 Document 風格的 Web Service 又太過難用。

Web Service 沒有解決用戶的真正問題，只是把一個問題變成了另一個問題。

Web Service 的規(guī)范太過復雜，以至于在 .NET 和 Java 平臺以外沒有真正好用的實現(xiàn)，甚至沒有可用的實現(xiàn)。

跨語言跨平臺只是 Web Service 的一個口號，雖然很多人迷信這一點，但事實上它并沒有真正實現(xiàn)。

PHPRPC

基于 PHP 內(nèi)置的序列化格式，在跨語言的類型映射上存在硬傷。

通訊上依賴于 HTTP 協(xié)議，沒有其它底層通訊方式的選擇。

內(nèi)置的加密傳輸既是特點，也是缺點。

雖然比基于 XML 的 RPC 速度快，但還不是足夠快。

Hessian

二進制的數(shù)據(jù)格式完全不具有可讀性。

官方只提供了兩個半語言的實現(xiàn)(Java，ActionScript 和不怎么完美的 Python 實現(xiàn))，其它語言的第三方實現(xiàn)良莠不齊。

支持的語言不夠多，對 Web 前端的 JavaScript 完全無視。

雖然是動態(tài) RPC，但動態(tài)性仍然欠佳。

雖然比基于 XML 的 RPC 速度快，但還不是足夠快。

JSON-RPC

JSON 具有文本可讀性，且比 XML 更簡潔。

JSON 受 JavaScript 語言子集的限制，可表示的數(shù)據(jù)類型不夠多。

JSON 格式無法表示數(shù)據(jù)內(nèi)的自引用，互引用和循環(huán)引用。

某些語言具有多種版本的實現(xiàn)，但在類型影射上沒有統(tǒng)一標準，存在兼容性問題。

JSON-RPC 雖然有規(guī)范，但是卻沒有統(tǒng)一的實現(xiàn)。在不同語言中的各自實現(xiàn)存在兼容性問題，無法真正互通。

Microsoft WCF，WebAPI

它們是微軟對已有技術(shù)的一個 .NET 平臺上的統(tǒng)一封裝，是對 .NET Remoting、WebService 和基于 JSON 、XML 等數(shù)據(jù)格式的 REST 風格的服務等技術(shù)的一個整合。

雖然號稱可以在 .NET 平臺以外來調(diào)用它的這些服務，但實際上跟在 .NET 平臺內(nèi)調(diào)用完全是兩碼事。它沒有提供任何在其他平臺的語言中可以使用的任何工具。

ZeroC Ice，Thrift，GRPC

初代 RPC 技術(shù)的跨語言面向?qū)ο蟮幕貧w。

仍然需要通過中間語言來編寫類型和接口定義。

仍然需要用代碼生成器來將中間語言編寫的類型和接口定義翻譯成你所使用的編程語言的客戶端和服務器端的占位程序(stub)。

你必須要基于生成的服務器代碼來單獨編寫服務，而不能將已有代碼直接作為服務發(fā)布。

你必須要用生成的客戶端代碼來調(diào)用服務，而沒有其它更靈活的方式。

如果你的中間代碼做了修改，以上所有步驟你都要至少重復一遍。

Hprose

無侵入式設計，不需要單獨定義類型，不需要單獨編寫服務，已有代碼可以直接發(fā)布為服務。

具有豐富的數(shù)據(jù)類型和完美的跨語言類型映射，支持自引用，互引用和循環(huán)引用數(shù)據(jù)。

支持眾多傳輸方式，如 HTTP、TCP、Websocket 等。

客戶端具有更靈活的調(diào)用方式，支持同步調(diào)用，異步調(diào)用，動態(tài)參數(shù)，可變參數(shù)，引用參數(shù)傳遞，多結(jié)果返回(Golang)等語言特征，Hprose 2.0 甚至支持推送。

具有良好的可擴展性，可以通過過濾器和中間件實現(xiàn)加密、壓縮、緩存、代理等各種功能性擴展。

兼容的無差別跨語言調(diào)用

支持更多的常用語言和平臺

支持瀏覽器端的跨域調(diào)用

沒有中間語言，無需學習成本

性能卓越，使用簡單

總結(jié)

以上是生活随笔為你收集整理的python rpc webservice_关于RPC、HTTP、WebService的区别的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。