是否允许使用 409 Conflict 状态码来防止在 HTTP PUT 请求中更新某些字段
Posted
技术标签:
【中文标题】是否允许使用 409 Conflict 状态码来防止在 HTTP PUT 请求中更新某些字段【英文标题】：Is it allowed to use the 409 Conflict status code to prevent some fields from being updated in a HTTP PUT request 【发布时间】：2016-11-23 22:36:00 【问题描述】：在处理 (json) REST API 时，我遇到了这样一种情况，即我们有一个 user 资源的表示形式，我想防止在 PUT 中覆盖字段 (email)。如果我理解正确，那么 PUT 应该包含资源的完整表示来替换旧的。
因此，例如，从 API 获取用户时（为简单起见，省略了一些标头）：
> GET /user/123 HTTP/1.1
> Host: example.com
> Authorization: Bearer XXXXX
> Accept: application/json
< HTTP/1.1 200 OK
< Content-Type: application/json
<
< "name": "John Smiht"
< , "email": "john.smith@example.com"
<
如果你想修正 John Smiths 名字中的错字，你会这样做：
> PUT /user/123 HTTP/1.1
> Host: example.com
> Content-Type: application/json
>
> "name": "John Smith"
> , "email": "john.smith@example.com"
>
< HTTP/1.1 201 No Content
现在，如果有人要输入不同的电子邮件地址，我是否可以使用 409 表示请求未处理？
> PUT /user/123 HTTP/1.1
> Host: example.com
> Content-Type: application/json
>
> "name": "John Smith"
> , "email": "something.else@example.com"
>
< HTTP/1.1 409 Conflict
< Content-Type: application/json
<
< "errorNumber": "XXX"
< , "errorMessage": "Not allowed to change e-mail address this way"
<
根据https://www.rfc-editor.org/rfc/rfc2616
400 Bad Request 表示语法格式错误（这不是） 可以使用403 Forbidden，但在我看来，它更多的是访问整个资源，而不是其中的一部分 409 Conflict 似乎是关于无法满足请求的技术原因，而不是关于有特权做某事。那么，我的问题是：我应该使用哪个状态码？
编辑：根据接受的答案；响应将变为
> PUT /user/123 HTTP/1.1
> Host: example.com
> Content-Type: application/json
>
> "name": "John Smith"
> , "email": "something.else@example.com"
>
< HTTP/1.1 403 Forbidden
< Content-Type: application/json
<
< "errorNumber": "XXX"
< , "errorMessage": "Not allowed to change e-mail address this way"
<
【问题讨论】：
【参考方案1】：我会说如果用户无权更改电子邮件地址 403 将是正确的代码，因为服务器理解用户但拒绝对其采取行动。 （通常意味着缺少范围/权限）
【讨论】：
好吧，我想我同意你的推理。接受它作为答案:-)以上是关于是否允许使用 409 Conflict 状态码来防止在 HTTP PUT 请求中更新某些字段的主要内容，如果未能解决你的问题，请参考以下文章
drop_download 中的错误：冲突 (HTTP 409)