摘要：相信未来REST规范将会变得更加流行和普及。
本文分享自华为云社区《云原生时代，远程服务调用和RESTful，如何分析和抉择？》，作者：breakDawn 。
随着云原生的概念越来越火，服务的架构应该如何发展和演进，成为很多程序员关心的话题。大名鼎鼎的《深入理解java虚拟机》一书作者于21年推出了新作《凤凰架构》，从这本书中可以看到当前时下很多最新的技术或者理念。
本博文将沉淀发布这本书的学习笔记和思考。 如果希望了解更加详细的内容，欢迎购买该书继续详细学习。
这一个章节主要讲解rpc的设计理念和发展历史。
先是讲解了IPC（进程间通信）所需要的各个必要因素
接着解释RPC 是IPC的一种特例（这是最初科学家们的想法）
但PRC存在很多可靠性的问题，并不能直接等同IPC的扩展。
接着提出了RPC的三个基本问题：
再后面讲解了rpc的发展历史
CORBA的使用过于复杂，被抛弃
SOAP使用xml很简单，但是性能奇差
可以看出RPC想同时满足简单、普适、高性能是很难的
于是得出一个结论：
不存在完美的RPC框架
最近几年的RPC框架更倾向于往高层次、插件化发展。
即不再独立解决RPC的所有问题，而是提供一些扩展点由用户自己选择（比如dubbo）
可以任意切换json或者fastjson等序列化方式
可以切换传输协议等。
rest并不是一种远程调用协议， 他只能说是一种风格。
REST的传输效率提升潜力有限，但是可以简化调用。
提供的api定义里总是包含了各种动作，例如
/queryXXX
/applyXXX
类似于RPC的行为接口
坏处是一旦要提供其他对XXX的操作，必须重新编写接口，无法对XXX的查询能力进行复用！
api的endpoint定义应该围绕名词+资源id而不是动词来定义。
POST /doctors/mjones 获取医生的档期
POST /schedules/{id} 触发对这个id的调度
上面的method都是POST，实际上可以把HTTP方法的method、返回码都给利用上
第2级里， 所有接口的定义仍然需要使用者自己查询文档来记忆和应用
实际上应该只需要一个操作起始入口， 例如获取医生的档期接口
这个接口要返回的body里，已经告知了对应资源的名称，例如档期资源的key就叫做schedules
那么就能马上知道下一个接口查询用schedules了！
这样代码里可以做好适配，当你要把档期的key名做修改时，客户端代码根本不用变动！
1.restful面向资源编程只适合做CRUD，不适合过于复杂的业务逻辑
2.rest不利于事务支持
作者不同意这个观点， 认为不会有阻碍，取决于系统的事务设计
3.rest没有传输可靠性支持
虽然确实没有类似于重发等机制的保证，但rest接口一般尽可能要求幂等性，来做到应用代码做重发时可以不用担心重复的问题
4.缺少对资源做部分或者批量处理的能力
rest语义里不能涵盖这种情况，得定义特殊的接口或者参数，那么低3级里面就不能涵盖了。
基于REST的规范，调用者可以非常快速地理解自己需要的接口内容是什么样的，例如华为云当前的很多云服务公开接口都会基于REST理念进行开放， 并且各云服务的开放接口都会集成到API Explorer和华为云SDK中心供开发者直接调用，这些平台提供了丰富的接口文档和示例代码，帮助开发者更快地上手和使用 REST 接口。
相信未来REST 规范将会变得更加流行和普及。随着云计算和大数据技术的不断发展，REST 接口将会被广泛应用于各种领域，例如医疗、金融、电商等。REST 接口的开放性、可扩展性和易用性，将会为开发者带来更加高效、便捷和可靠的开发体验。