ST vs RPC
REST式的Web服务和RPC式的Web服务在接口定义上的区别是，REST使用HTTP通用方法作为统一接口的标准词汇，REST式的Web服务所提供的方法信息都在HTTP方法里，而RPC式的web服务所提供的方法信息在SOAP/HTTP信封里（其封装的格式通常是HTTP或者是SOAP），每个RPC式的web服务都会公布一套符合自己商业逻辑的方法词汇。
RPC的典型案例
1. 百度lbs服务API
比如API: 行政区划区域检索，之所以是rpc，是由于：
- 在参数中指定了资源格式MIME（此例是json），就是说资源表述由百度官方自定义协议解释。
- 返回状态和错误信息封装在返回结果中，说明对于错误处理也由百度官方自定义协议解释。
- 返回结果关心的是满足当前接口数据，如果想进一步了解街道信息，客户端须根据获取街道信息API定义获取。
http://api.map.baidu.com/place/v2/search?query=ATM机&tag=银行®ion=北京&output=json&ak=您的ak GET
如果经过rest风格改造，行政区划区域检索API的返回结果可以是如下形式：
注：百度lbs不是面向应用状态迁移设计，因此采用rpc也是合适的。
2.Saleforce SOAP API
Saleforce提供了SOAP（简单对象访问协议） API,SOAP 通过发布WSDL（网络服务描述语言）文件来描述服务器提供的API的输入参数结构和返回数据结构以及可能的异常信息。客户端通过WSDL生成客户端调用代码（SOAP语言无关，可跨开发语言调用），就能调用远程的服务API。
下图表示表示了Saleforce的提供的API的WSDL：
注：Saleforce也提供了REST的API。
以下是二者的主要区别：
| HTTP协议地位 |
应用协议 |
传输协议或者不用 |
| 传输协议 |
HTTP |
HTTP或者TCP |
| 消息序列化类型 |
MIME |
MIME或者自定义协议 |
| 传输性能 |
中 |
高 |
| 服务处理性能 |
中 |
高 |
| 接口特点 |
通用（HTTP动作） |
自定义接口动作 |
| 应用协议 |
HTTP |
自定义 |
| 应用状态迁移方式 |
资源状态变化 |
业务数据状态变化 |
| 缓存扩展性 |
强 |
自定义 |
| 客户端耦合力度（协议） |
弱 |
强 |
| 客户端代码执行 |
按需提供（JS,CSS,HTML等） |
默认不支持 |
| 客户端的库支持 |
不需要 |
最好有，且和服务同步升级 |
| 防火墙穿透力 |
强 |
默认不支持 |
| 公网组件支持度 |
现成支持，包括（反向）代理服务器，防火墙，缓存服务器，用户代理（浏览器等） |
需自行支持（http传输除外） |
| 企业应用标准化程度 |
低（企业自定义） |
中（基于SOAP协议，各厂商产品容易集成） |
以下是主流RPC和REST框架
| Thrift |
Thrift是一个跨语言的RPC框架，自带的代码生成引擎大幅提高了开发效率，从而使它如此流行。
最初由Facebook团队设计开发，现在已贡献给Apache |
多语言 |
| Dubbo |
Dubbo是阿里巴巴开源的专门为Java设计的、成熟的RPC框架。支持基本的服务治理，所有服务治理
功能均在Client端集成：服务发现、负载均衡、容错、监控等 |
Java |
| Spring HATEOAS |
Spring HATEOAS 可以很方便创建 基于HATEOAS 原则的REST 风格接口 ，
但需要依赖于 Spring 和 Spring MVC |
Java |
6. 总结
HTTP的本意是方便应用系统实现REST的架构，不过人们在早期并没有意识到它的优点，因此目前更多使用的是RPC框架，因为REST 对开发人员的能力要求更高。综上，REST具有以下主要特点：
- 以HTTP为应用协议。
- 基于WEB中间件进行扩展：缓存代理提高缓存扩展，反向代理提供负载均衡和内外网协议转化（HTTPS和HTTP之间)。
- 请求的无状态：由于服务器没有会话上下文信息，提高系统的可伸缩性。缺点是传输冗余一些。
- 多级缓存：客户端代理，代理服务器，缓存服务器提供了强大缓存能力，提高了系统的可用性。
- 对资源内容的描述方式，比如MIME协商或者在此基础上的扩展格式，保证了系统的简单性和通用性。
- 资源状态变化促成应用状态迁移（HATEOAS），可使开发者以资源为中心建模，这种设计相对简单。
- 资源表述中链接广告了应用的状态流，但并不强迫客户端进行处理，有利于客户端平滑升级。