restful与rpc风格

在目前主流的三种Web服务交互方案中，REST相比于SOAP（Simple Object Access protocol，简单对象访问协议）以及XML-RPC更加简单明了，无论是对URL的处理还是对Payload的编码，REST都倾向于用更加简单轻量的方法设计和实现。
REST 指的是一组架构约束条件和原则。满足这些约束条件和原则的应用程序或设计就是 RESTful。

什么是restful，简称rest?
REST ：Representational State Transfer，表现层状态转换；是以 资源 为中心，使用统一的接口URL，使用GET、POST、PUT、PATCH、DELETE等操作方法，来处理资源。

restful风格的原则条件:
C/S结构、无状态：
Web 应用程序最重要的 REST 原则是，客户端和服务器之间的交互在请求之间是无状态的。
从客户端到服务器的每个请求都必须包含理解请求所必需的信息。如果服务器在请求之间的任何时间点重启，客户端不会得到通知。
可以cache：
此外，无状态请求可以由任何可用服务器回答，这十分适合云计算之类的环境。客户端可以缓存数据以改进性能。
统一的接口：
在服务器端，应用程序状态和功能可以分为各种资源。
资源是一个有趣的概念实体，它向客户端公开。资源的例子有：应用程序对象、数据库记录、算法等等。每个资源都使用 URI (Universal Resource Identifier) 得到一个唯一的地址。所有资源都共享统一的接口，以便在客户端和服务器之间传输状态。使用的是标准的 HTTP 方法，比如 GET、PUT、POST 和 DELETE。Hypermedia 是应用程序状态的引擎，资源表示通过超链接互联。
分层系统：
另一个重要的 REST 原则是分层系统，这表示组件无法了解它与之交互的中间层以外的组件。通过将系统知识限制在单个层，可以限制整个系统的复杂性，促进了底层的独立性。
当 REST 架构的约束条件作为一个整体应用时，将生成一个可以扩展到大量客户端的应用程序。它还降低了客户端和服务器之间的交互延迟。统一界面简化了整个系统架构，改进了子系统之间交互的可见性。REST 简化了客户端和服务器的实现。

以上的原则条件，完全同HTTP吻合！


RPC与REST的区别：
1.RPC通常使用TCP、UDP通讯协议，二进制方式的通讯协议，json序列化；Restful通常使用http通讯协议，json序列化。
2.RPC是以动词（操作方法）为中心；REST是以名词（资源）为中心。
3.RPC，在扩展的时侯，不方便。当你要需要加入新功能时,你必须要添加更多的动词, 这时候服务器端需要实现 相应的动词(方法), 客户端需要知道这个新的动词并进行调用。
REST，方便扩展。以名词为中心, 假使我请求的是 hostname/friends/, 无论这个URI对应的服务怎么变化,客户端是无需 关注和更新的,而这种变化对客户端也是透明的.
4示例：使用qq,向徽信聊天时，使用的是RPC风格；使用浏览器，通过http请求服务器资源，都是REST风格。

rpc观点：
rest以资源为中心，把对资源的操作归结为八种请求方法；对某些情况的API抽象非常糟糕，比如user login / resetpassword等等，无法顺当的融入到restful所定义的规范中的资源中。
restful的信徒，他们会说可以根据这个那个规范，把login / password等也纳入为某种资源，然后进行增删改查。这在我看来，纯粹是在解决一些原本不存在，根本不需要解决的问题，纯浪费。

所有的接口，服务器端原本就存在有相应的函数，它们本来就有自身的命名空间，接受的参数、返回值、异常等等。
采用轻便的方式暴露出来即可。
无需把一堆函数重新归纳到“资源”，再削减脑袋把所有的操作都映射为“增删改查”。
对应到web上，rpc的成熟方案非常多，有古老的soap，也有轻量的json rpc。
JSON rpc基本上仅是要求所有的请求必须有msg id，有函数名，然后可定义参数，并且区分返回值与异常；也可定义『命名空间』来对函数模块做划分。
这与大多数语言的模块、函数定义相符，使用起来是非常便利的。
很多json rpc是供web前端ajax调用，若前端调用抽象得当，调用远程API，实际上与调用本地函数无甚区别。
实际上，json rpc也未必需要跟http绑定，即便是在web上，它也可以走web socket，这样子，前端可以使用同一web socket管道批量发送请求，而服务器端乱序返回结果时，前端也可以根据msg id做准确的回调。
websocket，批量调用，乱序返回，这些都可以显著提高API的输出吞吐，这些是在json rpc的设计考量内。
调用更方便，性能也更好，两全其美是完全可能的。
想当然的为了“快”，为了“简单”就必须牺牲别的，这是严重的思维误区。
有些方案，纯粹就是糟糕的方案。
restful API仅适用与业务非常简单的场景，比方说，就是为了提供少量数据表单的增删改查。而这种场景实在是太过简单，实际中几乎找不到。

rest观点：
http vs 高性能二进制协议
http相对更规范，更标准，更通用，无论哪种语言都支持http协议。如果你是对外开放API，例如开放平台，外部的编程语言多种多样，你无法拒绝对每种语言的支持，相应的，如果采用http，无疑在你实现SDK之前，支持了所有语言，所以，现在开源中间件，基本最先支持的几个协议都包含RESTful。
RPC协议性能要高的多，例如Protobuf、Thrift、Kyro等，（如果算上序列化）吞吐量大概能达到http的二倍。响应时间也更为出色。千万不要小看这点性能损耗，公认的，微服务做的比较好的，例如，netflix、阿里，曾经都传出过为了提升性能而合并服务。如果是交付型的项目，性能更为重要，因为你卖给客户往往靠的就是性能上微弱的优势。
微服务的盛行，开放平台的盛行，的确让RESTful过于“流行”了。你可以看看，无论是Google、Amazon、netflix（据说很可能转向grpc），还是阿里，实际上内部都是采用性能更高的RPC方式。而对外开放的才是RESTful。
如果你的应用非常简单，无论用哪种都无所谓了，基本都能满足要求。


最后：
对外开放给全世界的API推荐采用RESTful，是否严格按照规范是一个要权衡的问题。要综合成本、稳定性、易用性、业务场景等等多种因素。
内部调用推荐采用RPC方式。当然不能一概而论，还要看具体的业务场景。