主页

索引

模块索引

搜索页面

常用

  • “表征状态转移”（Representational State Transfer）

  • 面向过程编程时，以算法和处理过程为中心，输入数据，输出结果。为了符合计算机世界中主流的交互方式。

  • 面向对象编程时，将数据和行为统一起来、封装成对象。为了符合现实世界的主流交互方式。

  • 面向资源编程时，将数据（资源）作为抽象的主体，把行为看作是统一的接口。为了符合网络世界的主流的交互方式:

    把问题空间中的数据对象作为抽象的主体，
把解决问题时从输入数据到输出结果的处理过程，看作是一个（组）数据资源的状态不断发生变换而导致的结果

面向资源编程是符合目前网络主流的交互方式，
也因此 REST 常常被看作是为基于网络的分布式系统量身定做的交互方式。

备注

对于这种存在争议性大的东西，尽可能的少引入团队，争议性大就意味着大家对他的理解的共性越少，无论是引入推广还是实施的具体效果都会存在很长周期的磨合与统一。引入它带来认知负荷的提高，弊端就很可能完全盖过了收益。

备注

REST APIs are excellent at handling requests in a generic way, establishing a set of rules that allow a large number of known and unknown developers to easily consume the services that the API offers. 解读: 适合做public API。提供确定 API作为规则，供各种消费者消费。

与RPC对比

备注

无论是『思想』上、『概念』上，还是使用范围上，REST 与 RPC 都不完全一样，它们在本质上并不是同一个类型的东西，充其量只算是有一些相似，在应用中会有一部分功能重合的地方。

『思想』上:

REST 与 RPC 在思想上存在差异的核心，是抽象的目标不一样，
也就是『面向资源』的编程思想与『面向过程』的编程思想之间的区别。

『概念』上:

REST 并不是一种协议:
因为协议都带有一定的规范性和强制性，最起码也该有个规约文档，
比如 JSON-RPC，它哪怕再简单，也要有个《JSON-RPC Specification》来规定协议的格式细节、异常、响应码等信息。
但是 REST 并没有定义这些内容，虽然它有一些指导原则，但实际上并不受任何强制的约束。

备注

在『使用范围』上，REST 与 RPC 作为主流的两种远程调用方式，在使用上确实有重合之处，但重合的区域有多大就见仁见智了。

『使用范围』上:

从RPC 的3个典型发展方向来对比RPC和REST:
1. 分布式对象
  与 REST 毫无关系

2. 提升调用效率
  a. REST 应用得最多是供「浏览器端」消费的远程服务:
  因为以浏览器作为前端，对于传输协议、序列化器这两点都没有什么选择权
  想要更高效率也有心无力。

  b. 在移动端、桌面端或者分布式服务端的节点之间通讯这一块:
  使用 REST 的前提是网络没有成为性能上的瓶颈。
  但是在需要追求传输效率的场景里，REST 提升传输效率的潜力有限

3. 简化调用复杂性
  在众多 RPC 里，也就 JSON-RPC 有机会与 REST 竞争
  其他 RPC 协议与框架:
      哪怕是能够支持 HTTP 协议，
      哪怕提供了 JavaScript 版本的客户端（如 gRPC-Web）
      也只是具备前端使用的理论可行性，很少能看到有实际项目把它们真的用到浏览器上的

备注

尽管有着种种不同，REST 跟 RPC 还是产生了很频繁的比较与争论，这两种分别面向资源和面向过程的远程调用方式，就像当年面向对象与面向过程的编程思想一样，非得分出个高低不可。

参考

主页

索引

模块索引

搜索页面