补丁 http 方法的 REST full api 应该如何响应？答案

【问题标题】：what should response of REST full api for patch http method?补丁 http 方法的 REST full api 应该如何响应？
【发布时间】：2019-07-07 01:17:32
【问题描述】：

我在服务器上有一个订单资源。网址看起来像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 上提供补丁方法，以便可以更新/添加一些细节，如送货地址。要更新订单详情，可以在同一订单网址上使用补丁 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 的响应数据和格式的信息。

【问题讨论】：

可能值得一看stackoverflow.com/questions/37718119/…

标签： rest

【解决方案1】：

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

补丁在RFC 5789 中定义。第 2 节演示了一种可能性是您将返回资源的更新表示：

仅当此方法的响应包含明确的新鲜度信息（例如 Expires 标头或“Cache-Control: max-age”指令）以及与 Request-URI 匹配的 Content-Location 标头时，它才是可缓存的，表明PATCH 响应正文是一种资源表示。

但我找不到更一般情况的规范。所以我建议将RFC 7231 的规范解释为 PUT 和 DELETE 也适用于 PATCH

动作状态的表示

【讨论】：

【解决方案2】：

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

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

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

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

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

【讨论】：