问一个可能有点愚蠢的问题

[alangz]

一直以来对RPC和REST Service的区别有一些疑惑，REST Service用的比较多还算明白。对于RPC，知道有实现了它的框架，例如Thrift。单就Thrift和RESTful API来说，两者着都可构建跨语言的调用。那么Thrift相比RESTful API有何优势，应用场景有哪些？

[mucid]

Thift是二进制传输协议性能好吧，
Rest一般是HTTP上实现的一套规范，只是规范，
终究还是HTTP通行完备可靠性好，可以传输复杂的数据

[alangz]

这里的RESTful API特指构建于JSON-HTTP上的

[kaneg]

以下是个人的一些理解：RPC只是一种思路，具体数据格式和传输手段可以多种多样，例如基于http的xml rpc，笼统的说soap等web service也可以说是一种rpc。而restful则是比较狭义的基于http的get/put/post等语意的一种交互手段

[oclock]

RESTful和thrift不是一个维度范畴的东西
你可以拿RESTful跟SOAP比较
或者thrift与protobuf比较
非要说RESTful与thrift比有何优势
好比问福克斯与米其林比有何优势

[alangz]

@oclock protobuf仅仅是一个序列化协议吧，thrift实现了RPC，而且thrift好像也可以使用protobuf，这两个也没有可比性，个人认为。

[JamesRuan]

看来还是没理解REST的精髓。

REST是没有链接层面客户端与共享的服务器端状态的，所有的状态都是通过资源的表现层明文体现，而REST则是操作这种表现层的一种规范。

RPC说的大概是：
C：服务器，你那里有一个我的一个资源，你帮我做一下我们之前约定f的改动吧！
S：好的，根据约定f，改动成功，结果如下。

而REST说的大概是：
C：服务器，这个资源我要这样用，你用r的表现方式返回这个资源实例的内容吧！
S：好的，r表现方式下是这样的。
C：（改动了资源在r表现方式下的内容），服务器，把这个按照r表现方式的内容做为这个资源的实例存起来吧！
S：好的，已经存好了。

RPC下，服务器知道如何改动资源的N种方式，这些需要和客户端共享，每个链接中都需要维护资源状态的改变。
REST下，服务器不知道资源如何改动，只知道资源的表现层要如何读写；至于实际资源表现层变动后，低层的逻辑如何变化，客户端不需要和服务器共享，服务器自己知道就好了，客户端只要知道，服务器报告它OK的时候，对其他相关连的资源的表现层内容已经变化了；对客户端来说只需要被操作资源的表现层状态转移OK了，而不需要在意资源间的内部联系的状态转移。

你可以用RPC的方式去实现一个REST，完全没有问题，只需要做到REST规范的那些就行了。

核心就是，客户端别去指挥服务器去做表现层以外的东西。