Question

我正在努力学习如何正确设计休息服务。你如何处理非纯粹CRUD并需要复杂响应的事情？我的玩具示例是

一个简单的库存系统接收一个数组为
的JSON消息从库存中获取的产品和数量。
产品ID标识的多个广告资源可能是他们的每次接收请求的数量减少了所要求的金额。
更新必须是事务中的原子。
任何导致负库存的减法都需要为传达回客户端，因为这意味着延期交货情况存在。

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

由于库存系统不知道任何订单，因此无需更新主资源。

请求可能看起来像
PUT：库存/采取
或
补丁：库存

我认为PATCH可能是＆＃34;正确的＆＃34;选择是否遵循REST准则但是如果我确实使用了PATCH，我可能应该修改JSON，使其更符合我阅读的操作。

JSON请求正文看起来像这样

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

这里的任何设计指导都将特别受到赞赏，特别是在现实世界中如何完成工作或任何有用的REST设计链接处理更复杂的事情然后CRUD将不胜感激。

Answer 1

不确定问题到底是什么，但这里有几个答案要素：

PUT是幂等的（或理论上应该是）。这意味着如果您将相同的请求两次PUT，它应该没有效果。显然情况并非如此，因为您在每次请求时都会减少数量，所以请忘记它。

您可以在资源PATCH上使用POST或/inventory。您的JSON适用于PATCH和POST。这真的取决于你是否想要务实（然后使用POST，它可以在任何地方工作）或理想主义（然后使用PATCH，它很酷和语义）。

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

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

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

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

你的API更通用（如果你只关心＆＃34;后退订单＆＃34;产品暂时，只需在remaining中查找负值的行并忽略其余的行）
无论是在库存中添加还是删除产品，响应都很有用
它还可以确保API处理了所有产品ID。如果结果中缺少产品ID，则API客户端可以检测到出现了问题。

基本CRUD之外的REST API设计

1 个答案: