Restful 和 RPC 是什么关系与区别

Restful 和 RPC 是什么关系

这两个不是互斥的，HTTP是不是RPC完全取决于client的具体形式。传统的RPC一般是基于二进制协议的，client发个二进制包过来（然后阻塞），server处理完回复一个包，client收到后醒来。在二进制协议中一般可以在包中加个id来指明回复和请求的对应关系，这样我们就能在一个tcp连接上同时发起多个请求和回复。HTTP这种文本协议也可以加id，但由于一些原因（Content-Length可能缺失），即使加了id也做不到一个连接上同时传多个HTTP消息，所以HTTP协议一般会和server保持多个连接，每个连接上同时最多只有一个HTTP消息。此种”连接池“方式即为HTTP中的”Keep-alive“。所以即使在HTTP上（或任何协议上），我们仍然可以做到高效地发送一个请求过去，阻塞，等待server处理完后，再醒来。这不就是RPC么。所以这儿的选择更多是平衡功能和性能。一般来说，面向终端用户的尽量用Restful HTTP。原因是认知广，直观，编程语言都支持HTTP（包括shell，这样调试起来方便），性能不是那么重要，方便用户share链接。而面向内部系统的话如果机器不多也可以考虑用Restful HTTP，如果机器很多还是尽量用二进制的RPC吧，毕竟性能差距还是很大的。

restful架构与rpc区别

RPC

RPC 即远程过程调用， 很简单的概念， 像调用本地服务（方法）一样调用服务器的服务（方法）。

通常的实现有 XML-RPC ， JSON-RPC ， 通信方式基本相同， 所不同的只是传输数据的格式。

（如果你已经习惯于XML繁重的尖括号，你不妨可以尝试下更加轻型，高效，传输效率高的 JSON.）

一个简单的通信过程通常为：

Request

<？xml version=“1.0”？>

member.get_username_by_id

Response

<？xml version=“1.0”？>

Zhu Tao

向服务器发送一个过程调用的方法及其参数， 得到服务器返回的方法执行的结果。

REST

REST 不是一种协议，它是一种架构， 一种 Web Service 能够如果满足 REST 的几个条件， 通常就称这个系统是 Restful 的。

这里提到的条件包括：

C/S结构 （这是Internet服务的一个基本特征）

无状态 （很熟悉吧，呵呵）

可以cache （想起了浏览器？）

分层系统 （想起了无数的架构？）

统一的接口 （如果这是可能的，程序员有福了， ：D）

code on demand（可选， 其实是一种扩展性的要求）

看了这几个特征后，你想起了什么？

你可能会破口而出： HTTP.

我答： You got it！

HTTP是WWW的最核心的协议， 它将简单的分布于世界各个角落的资源都统一起来， 统一的地址， 简单的方法， 和一定数量的表达方式。（你可能对这三点描述很模糊，请go ahead）。

REST 的三个要素是 唯一的资源标识， 简单的方法 （此处的方法是个抽象的概念）， 一定的表达方式。

REST 是以 资源 为中心， 名词即资源的地址， 动词即施加于名词上的一些有限操作， 表达是对各种资源形态的抽象。

以HTTP为例， 名词即为URI（统一资源标识）， 动词包括POST， GET， PUT， DELETE等（还有其它不常用的2个，所以 整个动词集合是有限的）， 资源的形态（如text， html， image， pdf等）

RPC与REST的区别

如果你想只记住一点，那么就请记住 RPC是以动词为中心的， REST是以名词为中心的， 此处的 动词指的是一些方法， 名词是指资源。

你会发现，以动词为中心，意味着，当你要需要加入新功能时，你必须要添加更多的动词， 这时候服务器端需要实现 相应的动词（方法）， 客户端需要知道这个新的动词并进行调用。

而以名词为中心， 假使我请求的是 hostname/friends/， 无论这个URI对应的服务怎么变化，客户端是无需 关注和更新的，而这种变化对客户端也是透明的。

至于其它的区别，如对实现语言的依赖， 耦合性等，这些都是上面提到的这个根本区别所衍生的。

让我们回到引入部分的2个问题。 当你每天使用HTTP冲浪时，你都在使用 REST 与远程的服务器进行亲密接触。 当你使用Gtalk和同事朋友沟通时，你则是在享受着 RPC 的便利.