REST设计超越基本CRUD

Question

我正在努力学习如何正确地设计restful服务。你如何处理那些不是简单的CRUD并且需要一个复杂的响应的事情？我的玩具例子是

• 简单的库存系统接收JSON消息，该消息的数组为 从库存中提取的产品和数量。
• 由产品id标识的多个库存资源可以在每次获取请求时将其数量减少所请求的数量。
• 更新在事务中必须是原子的。
• 任何导致负库存的减数都必须是 与客户沟通，因为这意味着有退货的情况存在。

这通常的用例是在订单系统上提交订单时，它必须告诉库存系统更新。此更新是部分的，因为只有尝试更新时才能知道存在的库存数量。

没有要更新的主资源，因为库存系统对订单一无所知。

请求看起来可能类似于

放置:库存/取走

或

补丁:库存

我认为，如果遵循REST准则，补丁可能是“正确”的选择，但如果我确实使用了修补程序，我可能应该修改JSON，使之与我所读到的操作更加通用。

JSON请求体看起来如下所示

        [
          {
            productId: 1, 
            quantity: 2
          }
          {
            productId:  10, 
            quantity: 3
          } 
       ]

这里的任何设计指南都会受到赞赏，特别是在现实世界中是如何完成的，或者任何与REST设计有关的有用链接，这些链接处理的事情会更复杂，CRUD也会很感激。

Answer 1

不确定问题到底是什么，但以下是一些回答的要素：

PUT 是幂等的(或者理论上应该是)。这意味着，如果你提出同样的要求两次，它应该没有任何效果。这里显然不是这样的，因为每次请求都在减少数量，所以算了吧。

您可以在资源PATCH上使用POST或/inventory。您的JSON看起来对PATCH和POST都很好。这真的取决于你是否想变得务实(然后使用POST，它会在任何地方工作)或理想主义(然后使用PATCH，它是酷的和语义的)。

就我个人而言，我认为在将产品从库存中提取出来时，发送负值的数量和在重新进货时发送正的数量会更有意义。这样，您就可以对两个操作使用相同的端点。

关于响应，我个人认为返回列表(请求中传递的所有产品)和更新的剩余数量是有意义的。例如：

[
  { productId: 1, remaining: 12 },
  { productId: 10, remaining: -1 }
]

返回与请求中相同的产品列表有许多优点：

• 您的API更通用(如果您现在只关心"back order“产品，只需在remaining中查找带有负值的行，而忽略其余的)
• 无论是从库存中添加产品还是从库存中删除产品，响应都是有用的。
• 这也是一种确保所有产品ID都已被API处理过的方法。如果结果中缺少产品ID，API客户端可以检测到某些地方出错了。