修补程序http方法的REST完整api响应应如何?

时间:2019-02-13 09:05:36

标签: rest

我在服务器上有一个订单资源。网址看起来像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的响应数据和格式的任何文档。

2 个答案:

答案 0 :(得分:1)

  

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

修补程序在RFC 5789中定义。第2部分演示了一种可能性,您将返回该资源的更新表示:

  

对此方法的响应只有在包含显式的新鲜度信息(例如Expires标头或“ Cache-Control:max-age”指令)以及与Request-URI相匹配的Content-Location标头时,才可以缓存。 PATCH响应主体是资源表示。

但是我无法找到更一般情况的规范。因此,我的建议是,将RFC 7231中对PUT和DELETE的规范解释为也适用于PATCH

  

动作状态的表示

答案 1 :(得分:1)

  

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

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

该规范提出了一个204 No Content示例,因为从广义上讲,补丁由客户端计算出的一组指令组成,服务器应使用这些指令将目标资源转换为所需状态。因此,客户端可以事先知道最终结果的外观,因此服务器无需将其告知客户端。

如果要返回200 OK响应,我建议返回由客户端发出的Accept请求标头建议的表示形式(Content-Type协商),以避免强迫客户端进行某些操作预定义的媒体类型格式,可能无法理解或从中推断出更多的可能性。

如果您需要对资源进行不可预测的更改,即基于服务器端进行的某些计算,或者将有效负载包含到某个预定义的元素中(如您的示例中可能所做的那样),则RFC 5789明确声明{{1 }}应该代替POSTPUT使用。进一步注意,您可以支持PATCH媒体格式及其在RFC 7386中定义的语义,以将这样的(样本)主体作为有效载荷发布到application/merge-patch+json请求中,并可能实现所需的结果