我在服务器上有一个订单资源。网址看起来像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的响应数据和格式的任何文档。
答案 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 }}应该代替POST
或PUT
使用。进一步注意,您可以支持PATCH
媒体格式及其在RFC 7386中定义的语义,以将这样的(样本)主体作为有效载荷发布到application/merge-patch+json
请求中,并可能实现所需的结果