对于 patch http 方法，REST 完整 api 应该响应什么？

Question

我在服务器上有一个订单资源。url 看起来像http://example.net/order/1 上面的 url 上的 get 方法将返回整个订单对象，例如

    {
    "orderNo": "1",
    "status": "order place",
    "orderTimestamp": "2018-11-22 14:28:12",
   "invoiceAddress": {
        "salutation": "M",
        "firstName": "Dieter",
        "lastName": "Wolf",
        "companyName": "",
        "street": "Michaelkirchstr.",
        "houseNo": "16",
        "zipCode": "31604",
        "city": "Raddestorf",
        "countryIsoCode": "DEU",
        "phone": "05763 82 60 80",
        "email": "DieterWolf@armyspy.com"
    },
    "deliveryAddress": {}
    "items": [
        {
            ...
        }
    ],
    "returnItemsDetails": []
}

现在我希望在同一 api 上提供修补方法，以便可以更新/添加一些详细信息，例如送货地址。要更新订单详细信息，可以在同一订单 url 上使用 patch http 方法请求以下请求

{
    "deliveryAddress": {
        "deliveryType": "CUSTOMER",
        "salutation": "M",
        "firstName": "Dieter",
        "lastName": "Wolf",
        "companyName": "",
        "street": "Michaelkirchstr.",
        "houseNo": "16",
        "zipCode": "31604 ",
        "city": "Raddestorf",
        "countryIsoCode": "DEU",
        "phone": "05763 82 60 80",
        "email": "DieterWolf@armyspy.com"
    }
}

我的问题是，根据 REST 标准，补丁请求的响应应该是什么？或者是否有任何文档可以找到有关 REST api 的响应数据和格式的信息。

Answer 1

我的问题是，根据 REST 标准，补丁请求的响应应该是什么？或者是否有任何文档可以找到有关 REST api 的响应数据和格式的信息。

根据RFC 5789，成功的响应可以返回任何成功代码（即 200 或 204）。理想情况下，它还应该包含一个 ETag 标头，以允许客户端跟踪最终连续请求的当前版本（这基本上用于资源状态的乐观锁定）。

该规范提供了一个204 No Content补丁示例，从广义上讲，它由客户端计算的一组指令组成，服务器应应用这些指令将目标资源转换为所需状态。因此客户端事先知道最终结果应该是什么样子，因此服务器不需要通知客户端。

如果您想返回200 OK响应，我建议返回客户端发出的请求标头建议的表示Accept（内容类型协商），以避免强制客户端使用某些预定义的媒体类型格式，它可能无法理解或推断进一步的可能性。

如果您需要对资源应用不可预测的更改，即基于服务器端完成的一些计算或将有效负载包含到某个预定义元素（可能在您的示例中完成），RFC 5789 明确指出应该使用POST代替PUT或PATCH。进一步注意，您可以支持RFC 7386application/merge-patch+json中定义的媒体格式及其语义，以将此类（示例）主体作为请求的有效负载发出，并可能实现您想要的结果。PATCH