关于 REST 上面已经介绍的很多了，这里对 RPC 部分做一个补充：

RPC(远程过程调用)是什么

• 简单的说，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 甚至支持推送。
• 具有良好的可扩展性，可以通过过滤器和中间件实现加密、压缩、缓存、代理等各种功能性扩展。
• 兼容的无差别跨语言调用
• 支持更多的常用语言和平台
• 支持浏览器端的跨域调用
• 没有中间语言，无需学习成本
• 性能卓越，使用简单

补充一下，欢迎拍砖。

对于PRC的概念不太清楚，貌似在.NET中接触到的也不太多，就说说SOAP和REST吧。

SOAP和REST严格来说不是两个对等的概念，姑且理解成两种服务设计思想和及其具体的实现架构吧。

正如前文有大牛回答的，二者各有自己的使用场景。如果创建的分布式服务要求较好的安全性，对于传输等底层实现要求较强的可定制性，可以考虑SOAP；如果要求设计实现简单，一般来说安全性要求不高可以考虑REST。这只是一般情况，但偏于面向资源的服务使用REST有天然的优势。

就我们的项目来说，SOAP在.NET中现在经常使用WCF框架，而RESTful则多使用Web API。WCF中虽然也有RESTful实现，但并不好用。

就我个人当前体会目前是这么多。

SOAP,REST,and More
这篇微软杂志上的文章应该可以帮助题主理解，内容略长，慢慢撸。

RESTful是一种前端与后台通过http协议获取数据准。对后台数据的操作无非就是CRUD，C（Create）就对应着http协议的post方法，R（Retrieve）对应get方法，U（Update）对应着put方法，D（Delete）对应着delete方法。
个人感觉RESTful非常的简单，轻便。以前的WebService方法就显得复杂，过时了。

rest 主要是基于http之上建立的一种接口规范，核心是资源。soap是一种协议，以xml格式传输。rpc是远程方法调用大多是基于tcp之上

刚好可以总结一下自己对这几个东西的理解。不对之处请指正，欢迎讨论

第一个问题： 什么是RESTful ？

REST这个词，是 Roy Thomas Fielding 在他2000年的博士论文中提出的。有兴趣可以看看这里 论文 `，谁是Fielding?点击前面名字了解。

那 RESTful 到底是什么呢？简单的讲，它是： 一种架构设计风格，提供了设计原则和约束条件 ，而不是架构。而满足这些约束条件和原则的应用程序或设计就是 RESTful 架构或服务。

推荐阅读： 张善友博客——REST 入门介绍

infoq——深入浅出REST

第二个问题： 到底 REST 和 SOAP、RPC 有何区别？

这个问题比较大，要知道他们有什么区别首先需要明白，他们分别是什么？

• REST 上面已经简单的说明了它是什么。

• SOAP (简单对象访问协议)是什么？ SOAP是一种数据交换协议规范，是一种轻量的、简单的、基于XML的协议 的规范。它有什么优点？简单总结为： 易用，灵活，跨语言，跨平台 。

  易用 ：是因为它的消息是基于 xml 并封装成了符合 http 协议，因此,它符合任何路由器、 防火墙或代理服务器的要求。

  灵活 ：表现在极具拓展性，SOAP 无需中断已有的应用程序, SOAP 客户端、 服务器和协议自身都能发展。而且SOAP 能极好地支持中间介质和层次化的体系结构。

  跨语言 ： soap 可以使用任何语言来完成，只要发送正确的 soap 请求即可。

  跨平台 ：基于 soap 的服务可以在任何平台无需修改即可正常使用。

• RPC(远程调用框架) 是一种允许分布式应用程序调用网络上不同计算机的可用服务的机制。涉猎不多，一下省略256个字。 有熟悉的朋友可以在评论补充，然后我会修改到该内容中去

从上面我们可以看出， REST 和 SOAP、RPC 有何区别 呢？没什么太大区别，他们的本质都是提供可支持分布式的基础服务，最大的区别在于他们各自的的特点所带来的不同应用场景。

REST 可以看着是 http 协议的一种直接应用，默认基于 json 作为传输格式，使用简单，学习成本低效率高，~~但是安全性较低~~，而 SOAP 可以看着是一个重量级的协议，基于 xml ， SOAP 在安全方面是通过使用 XML-Security 和 XML-Signature 两个规范组成了 WS-Security 来实现安全控制的，当前已经得到了各个厂商的支持，.net ，php ，java 都已经对其有了很好的支持 。这是 REST 薄弱的地方。

以上