PATCH 与 PUT 更新账单答案

【问题标题】：PATCH vs PUT for Update BillPATCH 与 PUT 更新账单
【发布时间】：2020-01-09 00:02:15
【问题描述】：

我们有一个库存功能，我们可以在其中生成账单。有一个 Edit Bill API 调用。我们很困惑将其实现为 PATCH 或 PUT。

假设我们的 BillLineItem 包含

{
   stockId
   quantity
   rate
}

id = 1 的账单有 2 个 LineItem：

|  Stock Id |   Qty        |  Rate       |
|    10     |      2       |    10       |
|    11     |      3       |    20       |

现在假设我想更改 quantity for stock Id : 10 to 5 和我要改rate for stock Id : 11 to 40

我是否应该将其表示为 PUT 调用如下：

bill : {
id : 1

lineItems : [
{
    stockId : 10,
    qty : 5,
    rate : 10   
 },

 {
    stockId : 11,
    qty : 3,
    rate : 40   
 }
]
}

我是否应该将其表示为 PATCH 调用如下：

 bill : {
    id : 1

    lineItems : [
    {
        stockId : 10,
        qty : 5,
     },

     {
        stockId : 11,
        rate : 40   
     }
    ]
    }

还有其他参数，如 discountType、discountValue 作为 BillLineItem 的一部分，我在上面的示例中没有显示。

【问题讨论】：

就编码而言，使用 PATCH、PUT 或 POST 没有区别。他们都只是将数据发送到服务器，它可以用它做任何事情。
如果您正在实现 REST API，PATCH 最适合您修改对象而不是完全替换它们。见en.wikipedia.org/wiki/…

标签： rest patch put

【解决方案1】：

我们很困惑将其实现为 PATCH 或 PUT。

PUT 和 PATCH 都具有远程创作语义；松散地说，这两个都是请求服务器更改其资源副本以具有与客户端副本相同的表示形式。

PUT 是直接“使您的副本像我在此请求中包含的副本一样”。 PATCH 是“将这些更改应用到您的副本”。

因此PUT 是idempotent；同一请求的两个副本与请求的单个副本具有相同的效果。这个语义提示在不可靠的网络上可能很重要——如果PUT 请求丢失，我们可以重新发送它。此外，重新发送消息是安全的提示既是标准的，也包含在消息本身中；这意味着任何看到消息的通用组件都会知道重新发送是安全的。

PATCH 没有内置幂等语义——如果消息丢失，通用组件不知道请求是否可以安全地重复，因此它需要失败，而不是重试。

对于PUT 来说，这是一个相当大的胜利。

但是，当资源非常大（也就是说，比 HTTP 标头大得多），并且您所做更改的大小很小时，只发送对表示的修订可能是有意义的，而不是整个事情。在这种情况下，使用PATCH 可能是更好的选择。

REST 的部分意义在于我们使用“易于标准化的形式”进行通信，因此您应该尽可能支持标准化的补丁文档格式（application/json-patch+json 或 application/merge-patch+json），而不是自己发明定制代表。

【讨论】：

这很有帮助。我将尝试坚持“易于标准化的形式”。感谢您指出这个方向。

【解决方案2】：

Wikipedia描述了HTTP方法对应RESTful操作的典型方式：

PUT - 将集合资源的成员资源的所有表示替换为请求正文中的表示，如果集合资源不存在则创建。
@987654323 @ - 更新集合资源的成员资源的所有表示使用请求正文中的指令，或者可以创建如果集合资源不存在。 p>

由于您要更新账单项目的各个属性而不是完全替换它们，所以PATCH 是合适的方法。

【讨论】：