- RPC：所謂的遠程過程調用 (面向方法)
- SOA：所謂的面向服務的架構(面向消息)
- REST：所謂的 Representational state transfer (面向資源)
RPC 即遠程過程調用, 很簡單的概念, 像調用本地服務(方法)一樣調用服務器的服務(方法).
通常的實現有 XML-RPC , JSON-RPC , 通信方式基本相同, 所不同的只是傳輸數據的格式.
REST 的三個要素是 唯一的資源標識, 簡單的方法 (此處的方法是個抽象的概念), 一定的表達方式.
重要的特性：無狀態
個人也比較喜歡REST,目前基本主流開放平台都是使用這個（淘寶開放平台／人人網／facebook...)
Web Service 已經是過時之物，平常基本使用甚少，建議不要在折騰它了
PC(遠程過程調用)是什么
- 簡單的說，RPC就是從一台機器（客戶端）上通過參數傳遞的方式調用另一台機器（服務器）上的一個函數或方法（可以統稱為服務）並得到返回的結果。
- RPC 會隱藏底層的通訊細節（不需要直接處理Socket通訊或Http通訊）
- RPC 是一個請求響應模型。客戶端發起請求，服務器返回響應（類似於Http的工作方式）
- RPC 在使用形式上像調用本地函數（或方法）一樣去調用遠程的函數（或方法）。
遠程過程調用發展歷程
- ONC RPC （開放網絡計算的遠程過程調用），OSF RPC（開放軟件基金會的遠程過程調用）
- CORBA（Common Object Request Broker Architecture公共對象請求代理體系結構）
- 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 太復雜，各種不同實現不兼容，一般程序員也玩不轉。
- DCOM，COM+ 逃不出 Windows 的手掌心。
- RMI 只能在 Java 里面玩。
- .NET Remoting 只能在 .NET 平台上玩。
XML-RPC，SOAP，WebService
- 冗余數據太多，處理速度太慢。
- RPC 風格的 Web Service 跨語言性不佳，而 Document 風格的 Web Service 又太過難用。
- Web Service 沒有解決用戶的真正問題，只是把一個問題變成了另一個問題。
- Web Service 的規范太過復雜，以至於在 .NET 和 Java 平台以外沒有真正好用的實現，甚至沒有可用的實現。
- 跨語言跨平台只是 Web Service 的一個口號，雖然很多人迷信這一點，但事實上它並沒有真正實現。
PHPRPC
- 基於 PHP 內置的序列化格式，在跨語言的類型映射上存在硬傷。
- 通訊上依賴於 HTTP 協議，沒有其它底層通訊方式的選擇。
- 內置的加密傳輸既是特點，也是缺點。
- 雖然比基於 XML 的 RPC 速度快，但還不是足夠快。
Hessian
- 二進制的數據格式完全不具有可讀性。
- 官方只提供了兩個半語言的實現（Java，ActionScript 和不怎么完美的 Python 實現），其它語言的第三方實現良莠不齊。
- 支持的語言不夠多，對 Web 前端的 JavaScript 完全無視。
- 雖然是動態 RPC，但動態性仍然欠佳。
- 雖然比基於 XML 的 RPC 速度快，但還不是足夠快。
JSON-RPC
- JSON 具有文本可讀性，且比 XML 更簡潔。
- JSON 受 JavaScript 語言子集的限制，可表示的數據類型不夠多。
- JSON 格式無法表示數據內的自引用，互引用和循環引用。
- 某些語言具有多種版本的實現，但在類型影射上沒有統一標准，存在兼容性問題。
- JSON-RPC 雖然有規范，但是卻沒有統一的實現。在不同語言中的各自實現存在兼容性問題，無法真正互通。
Microsoft WCF，WebAPI
- 它們是微軟對已有技術的一個 .NET 平台上的統一封裝，是對 .NET Remoting、WebService 和基於 JSON 、XML 等數據格式的 REST 風格的服務等技術的一個整合。
- 雖然號稱可以在 .NET 平台以外來調用它的這些服務，但實際上跟在 .NET 平台內調用完全是兩碼事。它沒有提供任何在其他平台的語言中可以使用的任何工具。
ZeroC Ice，Thrift，GRPC
- 初代 RPC 技術的跨語言面向對象的回歸。
- 仍然需要通過中間語言來編寫類型和接口定義。
- 仍然需要用代碼生成器來將中間語言編寫的類型和接口定義翻譯成你所使用的編程語言的客戶端和服務器端的占位程序（stub）。
- 你必須要基於生成的服務器代碼來單獨編寫服務，而不能將已有代碼直接作為服務發布。
- 你必須要用生成的客戶端代碼來調用服務，而沒有其它更靈活的方式。
- 如果你的中間代碼做了修改，以上所有步驟你都要至少重復一遍。
Hprose
- 無侵入式設計，不需要單獨定義類型，不需要單獨編寫服務，已有代碼可以直接發布為服務。
- 具有豐富的數據類型和完美的跨語言類型映射，支持自引用，互引用和循環引用數據。
- 支持眾多傳輸方式，如 HTTP、TCP、Websocket 等。
- 客戶端具有更靈活的調用方式，支持同步調用，異步調用，動態參數，可變參數，引用參數傳遞，多結果返回（Golang）等語言特征，Hprose 2.0 甚至支持推送。
- 具有良好的可擴展性，可以通過過濾器和中間件實現加密、壓縮、緩存、代理等各種功能性擴展。
- 兼容的無差別跨語言調用
- 支持更多的常用語言和平台
- 支持瀏覽器端的跨域調用
- 沒有中間語言，無需學習成本
- 性能卓越，使用簡單