RESTful API 架构
REST ***的几个特点为：资源、统一接口、URI 和无状态。
①资源
所谓"资源"，就是网络上的一个实体，或者说是网络上的一个具体信息。它可以是一段文本、一张图片、一首歌曲、一种服务，就是一个具体的实在。
②统一接口
RESTful 架构风格规定，数据的元操作，即 CRUD(Create，Read，Update 和 Delete，即数据的增删查改)操作，分别对应于 HTTP 方法：GET 用来获取资源，POST 用来新建资源(也可以用于更新资源)，PUT 用来更新资源，DELETE 用来删除资源，这样就统一了数据操作的接口，仅通过 HTTP 方法，就可以完成对数据的所有增删查改工作。
③URL
可以用一个 URI(统一资源定位符)指向资源，即每个 URI 都对应一个特定的资源。
要获取这个资源，访问它的 URI 就可以，因此 URI 就成了每一个资源的地址或识别符。
④无状态
所谓无状态的，即所有的资源，都可以通过 URI 定位，而且这个定位与其他资源无关，也不会因为其他资源的变化而改变。有状态和无状态的区别，举个简单的例子说明一下。
如查询员工的工资，如果查询工资是需要登录系统，进入查询工资的页面，执行相关操作后，获取工资的多少，则这种情况是有状态的。
因为查询工资的每一步操作都依赖于前一步操作，只要前置操作不成功，后续操作就无法执行。
如果输入一个 URI 即可得到指定员工的工资，则这种情况是无状态的，因为获取工资不依赖于其他资源或状态。
且这种情况下，员工工资是一个资源，由一个 URI 与之对应，可以通过 HTTP 中的 GET 方法得到资源，这是典型的 RESTful 风格。
RPC 和 Restful API 对比
面对对象不同：
- RPC 更侧重于动作。
- REST 的主体是资源。
RESTful 是面向资源的设计架构，但在系统中有很多对象不能抽象成资源，比如登录，修改密码等而 RPC 可以通过动作去操作资源。所以在操作的全面性上 RPC 大于 RESTful。
传输效率：
- RPC 效率更高。RPC，使用自定义的 TCP 协议，可以让请求报文体积更小，或者使用 HTTP2 协议，也可以很好的减少报文的体积，提高传输效率。
复杂度：
- RPC 实现复杂，流程繁琐。
- REST 调用及测试都很方便。
RPC 实现(参见***节)需要实现编码，序列化，网络传输等。而 RESTful 不要关注这些，RESTful 实现更简单。
灵活性：
- HTTP 相对更规范，更标准，更通用，无论哪种语言都支持 HTTP 协议。
- RPC 可以实现跨语言调用，但整体灵活性不如 RESTful。
总结
RPC 主要用于公司内部的服务调用，性能消耗低，传输效率高，实现复杂。
HTTP 主要用于对外的异构环境，浏览器接口调用，App 接口调用，第三方接口调用等。
RPC 使用场景(大型的网站，内部子系统较多、接口非常多的情况下适合使用 RPC)：
- 长链接。不必每次通信都要像 HTTP 一样去 3 次握手，减少了网络开销。
- 注册发布机制。RPC 框架一般都有注册中心，有丰富的监控管理;发布、下线接口、动态扩展等，对调用方来说是无感知、统一化的操作。
- 安全性，没有暴露资源操作。
- 微服务支持。就是最近流行的服务化架构、服务化治理，RPC 框架是一个强力的支撑。