REST 的不足与争议¶

第一个有争议的问题是：面向资源的编程思想只适合做 CRUD，只有面向过程、面向对象编程才能处理真正复杂的业务逻辑:

Google 推荐的 REST API 风格来拓展 HTTP 标准方法:
自定义方法: https://cloud.google.com/apis/design/custom_methods

自定义方法应该放在资源路径末尾，嵌入冒号加自定义动词的后缀,如(这儿的undelete):
POST /user/user_id/cart/book_id:undelete

第二个有争议的问题是：REST 与 HTTP 完全绑定，不适用于要求高性能传输的场景中:

面向资源编程与协议无关

第五个有争议的问题是：REST 缺乏对资源进行 “部分” 和 “批量” 的处理能力:

可能是未来面向资源的思想和 API 设计风格的发展方向。

HTTP 协议对 REST 的束缚:
1. 缺少对资源的 “部分” 操作的支持
  例: 只是想获得某个用户的姓名
    RPC 风格中可以设计一个 “getUsernameById” 的服务
    REST 风格需向服务端请求整个用户对象，然后丢弃掉返回结果中的其他属性，这就是一种请求冗余（Overfetching）。
2. 缺少对资源的 “批量” 操作的支持
  例: 给 1000 个用户的昵称加 “VIP” 前缀时
  例2: 在网店买东西的时候，下单、冻结库存、支付、加积分、扣减库存这一系列步骤会涉及多个资源的变化
      这时候我们就得创建一种 “事务” 的抽象资源，或者用某种具体的资源（比如 “结算单”）
      贯穿网购这个过程的始终，每次操作其他资源时都带着事务或者结算单的 ID
      对于 HTTP 协议来说，由于它的无状态性，相对来说不适用于（并非不能够）处理这类业务场景