我正在为客户管理系统编写一个RESTful服务，并试图找到部分更新记录的最佳实践。例如，我希望调用者能够使用GET请求读取完整的记录。但是为了更新它，只允许对记录进行某些操作，比如将状态从ENABLED更改为DISABLED。(我有比这更复杂的场景)
出于安全原因，我不希望调用者只提交更新字段的整个记录(这也感觉有点过分)。
是否有构造uri的推荐方法?在阅读REST书籍时，RPC样式的调用似乎是不受欢迎的。
如果下面的调用返回id为123的客户的完整客户记录
GET /customer/123
<customer>
{lots of attributes}
<status>ENABLED</status>
{even more attributes}
</customer>
我该如何更新状态?
POST /customer/123/status
<status>DISABLED</status>
POST /customer/123/changeStatus
DISABLED
...
更新:扩充问题。如何将“业务逻辑调用”合并到REST api中?有没有大家都同意的做法?并非所有的方法本质上都是CRUD。有些更复杂，如“sendEmailToCustomer(123)”，“mergeCustomers(123, 456)”，“countCustomers()”
POST /customer/123?cmd=sendEmail
POST /cmd/sendEmail?customerId=123
GET /customer/count
RFC 7396: JSON Merge Patch(在这个问题发布四年后发布)从格式和处理规则方面描述了Patch的最佳实践。
简而言之，您向目标资源提交一个HTTP PATCH，它带有application/merge-patch+json MIME媒体类型和一个只表示您想要更改/添加/删除的部分的主体，然后遵循以下处理规则。
规则:
如果提供的合并补丁包含未出现在目标中的成员，则会添加这些成员。
如果目标不包含该成员，则替换该值。
合并补丁中的空值被赋予特殊含义，以指示删除目标中的现有值。
演示上述规则的示例测试用例(见RFC的附录):
ORIGINAL PATCH RESULT
--------------------------------------------
{"a":"b"} {"a":"c"} {"a":"c"}
{"a":"b"} {"b":"c"} {"a":"b",
"b":"c"}
{"a":"b"} {"a":null} {}
{"a":"b", {"a":null} {"b":"c"}
"b":"c"}
{"a":["b"]} {"a":"c"} {"a":"c"}
{"a":"c"} {"a":["b"]} {"a":["b"]}
{"a": { {"a": { {"a": {
"b": "c"} "b": "d", "b": "d"
} "c": null} }
} }
{"a": [ {"a": [1]} {"a": [1]}
{"b":"c"}
]
}
["a","b"] ["c","d"] ["c","d"]
{"a":"b"} ["c"] ["c"]
{"a":"foo"} null null
{"a":"foo"} "bar" "bar"
{"e":null} {"a":1} {"e":null,
"a":1}
[1,2] {"a":"b", {"a":"b"}
"c":null}
{} {"a": {"a":
{"bb": {"bb":
{"ccc": {}}}
null}}}
RFC 7396: JSON Merge Patch(在这个问题发布四年后发布)从格式和处理规则方面描述了Patch的最佳实践。
简而言之，您向目标资源提交一个HTTP PATCH，它带有application/merge-patch+json MIME媒体类型和一个只表示您想要更改/添加/删除的部分的主体，然后遵循以下处理规则。
规则:
如果提供的合并补丁包含未出现在目标中的成员，则会添加这些成员。
如果目标不包含该成员，则替换该值。
合并补丁中的空值被赋予特殊含义，以指示删除目标中的现有值。
演示上述规则的示例测试用例(见RFC的附录):
ORIGINAL PATCH RESULT
--------------------------------------------
{"a":"b"} {"a":"c"} {"a":"c"}
{"a":"b"} {"b":"c"} {"a":"b",
"b":"c"}
{"a":"b"} {"a":null} {}
{"a":"b", {"a":null} {"b":"c"}
"b":"c"}
{"a":["b"]} {"a":"c"} {"a":"c"}
{"a":"c"} {"a":["b"]} {"a":["b"]}
{"a": { {"a": { {"a": {
"b": "c"} "b": "d", "b": "d"
} "c": null} }
} }
{"a": [ {"a": [1]} {"a": [1]}
{"b":"c"}
]
}
["a","b"] ["c","d"] ["c","d"]
{"a":"b"} ["c"] ["c"]
{"a":"foo"} null null
{"a":"foo"} "bar" "bar"
{"e":null} {"a":1} {"e":null,
"a":1}
[1,2] {"a":"b", {"a":"b"}
"c":null}
{} {"a": {"a":
{"bb": {"bb":
{"ccc": {}}}
null}}}
没关系。就REST而言，你不能做GET，因为它不是可缓存的，但不管你使用POST, PATCH, PUT或其他什么都没关系，URL看起来是什么也没关系。如果您正在使用REST，那么重要的是当您从服务器获得资源的表示时，该表示能够提供客户端状态转换选项。
如果您的GET响应有状态转换，客户机只需要知道如何读取它们，服务器可以根据需要更改它们。这里的更新是使用POST完成的，但是如果它被更改为PATCH，或者如果URL更改了，客户端仍然知道如何进行更新:
{
"customer" :
{
},
"operations":
[
"update" :
{
"method": "POST",
"href": "https://server/customer/123/"
}]
}
你可以列出必要的/可选的参数，让客户端反馈给你。这取决于应用程序。
就业务操作而言，这可能是与客户资源链接的不同资源。如果你想发送一封电子邮件给客户，也许该服务是它自己的资源，你可以POST，所以你可以在客户资源中包括以下操作:
"email":
{
"method": "POST",
"href": "http://server/emailservice/send?customer=1234"
}
以下是演示者REST架构的一些优秀视频和示例。Stormpath只使用GET/POST/DELETE，这很好，因为REST与你使用的操作或url的外观没有任何关系(除了GET应该是可缓存的):
https://www.youtube.com/watch?v=pspy1H6A3FM,
https://www.youtube.com/watch?v=5WXYw4J4QOU,
http://docs.stormpath.com/rest/quickstart/
