对于未找到某些链接资源的 PUT 操作，HTTP 404 是否是适当的响应? [英] Is HTTP 404 an appropriate response for a PUT operation where some linked resource is not found?

问题描述

想象一个 REST 网络服务，您可以在其中向某种类型的容器添加项目.例如，假设我们可以将参与者 #789 添加到活动 #456，如下所示:

PUT http://..../api/v1/events/456/attendees/789

如果事件 #456 或参与者 #789 不存在，返回 HTTP 404 是否正确(以及解释问题所在的详细错误负载，例如 { "error" : { "message": "Event 456 不存在" , "code" : "404" } }?

同样，如果我正在创建引用另一个对象的新对象，但另一个对象不存在怎么办?例如，假设我正在位置 #123

创建一个事件

PUT http://..../api/v1/event{ "location": 123, "name": "Party", "date": "2012-05-23", ...等... }

如果位置 #123 不存在，返回 404 是否也正确(以及响应的详细信息)?如果没有，什么是合适的 - 只是 400?

根据 HTTP 1.1 规范 http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html

<块引用>

9.6 PUT ... 如果资源不能用请求 URI 创建或修改，应该给出一个适当的错误响应来反映问题的性质

所以这似乎是对 404 响应的好投票.然而出于某种原因，我不能完全确定，用 404 响应 PUT(或 POST)似乎很奇怪对我来说...也许是因为404意味着找不到资源，但在这种情况下，我们的资源实际上是其他两个资源之间的链接，并且是这两个找不到的资源之一.

不要太担心我这里的具体例子——它们是为了说明这一点而编造的.主要问题是:404 是否是对因未找到链接资源而失败的 PUT 操作的适当响应?

如果您能指出参考文献就太好了——我很难找到任何涉及这种详细程度并且也足够可信的参考文献.尤其是在 REST API 设计中对资源关系的处理.

更新思路 我认为第一个示例可能应该返回 404，第二个示例不应该.原因是在第一种情况下，我们添加的资源使用事件 456 和参与者 789 作为复合主键；第二种情况位置只是一个外键.在第二种情况下，应该返回错误，而不是 404——可能是 412 Precondition Failed 或可能只是 400 Bad Request.想法?

解决方案

有多个 4xx HTTP 状态代码.最有可能的是 404 或 409:

<块引用>

404 未找到

<块引用>

服务器没有找到任何与有效请求 URI 匹配的内容.没有说明这种情况是暂时的还是永恒的.410 (Gone) 状态码应该被使用，如果服务器通过一些内部可配置的机制，知道一个旧的资源永久不可用且没有转发地址.当服务器不希望确切说明拒绝请求的原因，或当没有其他请求时响应是适用的.

<块引用>

409 冲突

<块引用>

由于与当前的冲突，请求无法完成资源的状态.仅在以下情况下才允许使用此代码预计用户可能能够解决冲突并重新提交请求.响应主体应该包括足够的供用户识别冲突来源的信息.理想情况下，响应表示将包含足够的信息供用户或用户代理解决问题；然而，这可能不可能，也不是必需的.

<块引用>

在响应 PUT 请求时最有可能发生冲突.为了例如，如果正在使用版本控制并且表示是PUT 包括对资源的更改，这些更改与较早的(第三方)请求，服务器可能会使用 409响应以指示它无法完成请求.在这在这种情况下，响应表示可能包含一个列表两个版本的区别.

其中任何一个都适合，但我想我会选择 409.404 用于 URI not found 但 409 表示资源的当前状态不允许请求的操作.在您的情况下，请求无法得到满足，因为出现了不允许的错误.

Imagine a REST webservice where you are adding items to some type of container. For example, lets say we could add a attendee #789 to a event #456 like this:

PUT http://..../api/v1/events/456/attendees/789

If either event #456 or attendee #789 do not exist, is it correct to return an HTTP 404 (along with a detailed error payload explaining what the problem was, e.g. { "error" : { "message" : "Event 456 does not exist" , "code" : "404" } }?

Similarly, what if I am creating something new which refers to another object, but the other object does not exist? For example, imagine I am creating an event at Location #123

PUT http://..../api/v1/event
{ "location": 123, "name": "Party", "date": "2012-05-23", ...etc... }

If Location #123 does not exist, is it also correct to return 404 (along with detail in response)? If not, what would be appropriate -- just a 400?

According to the HTTP 1.1 spec http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html

9.6 PUT ... If the resource could not be created or modified with the Request-URI, an appropriate error response SHOULD be given that reflects the nature of the problem

So that would seem to be a good vote for responding with 404. However for some reason I can't quite put my finger on, responding to PUT (or POST) with a 404 seems odd to me... Perhaps it's because 404 means that the resource cannot be found, but in this case our resource is actually a linkage between two other resources, and it's one of those two resources that can't be found.

Don't get too worried about my exact examples here -- they are made up to illustrate the point. The main question is: is 404 an appropriate response to a PUT operation that fails because a linked resource is not found?

It would be excellent if you can point to references -- I'm having a hard time finding any that get into this level of detail and are also sufficiently credible. Especially as regards treatment of resource relationships in REST API design.

Updated thinking I'm thinking that possibly the first example should return 404, the second should not. The reasoning being that in the first case the resource we're adding uses event 456 and attendee 789 as it's composite primary key; the second case location is only a foreign key. In the second case an error should be returned, but not a 404 -- possibly a 412 Precondition Failed or maybe just a 400 Bad Request. Thoughts?

解决方案

There are a number of 4xx HTTP status codes. The most likely are either 404 or 409:

404 Not Found

The server has not found anything matching the effective request URI. No indication is given of whether the condition is temporary or permanent. The 410 (Gone) status code SHOULD be used if the server knows, through some internally configurable mechanism, that an old resource is permanently unavailable and has no forwarding address. This status code is commonly used when the server does not wish to reveal exactly why the request has been refused, or when no other response is applicable.

409 Conflict

The request could not be completed due to a conflict with the current state of the resource. This code is only allowed in situations where it is expected that the user might be able to resolve the conflict and resubmit the request. The response body SHOULD include enough information for the user to recognize the source of the conflict. Ideally, the response representation would include enough information for the user or user agent to fix the problem; however, that might not be possible and is not required.

Conflicts are most likely to occur in response to a PUT request. For example, if versioning were being used and the representation being PUT included changes to a resource which conflict with those made by an earlier (third-party) request, the server might use the 409 response to indicate that it can't complete the request. In this case, the response representation would likely contain a list of the differences between the two versions.

Either of those would be suitable, but I think I'd go for 409. 404 is used for URI not found but 409 indicates the current state of the resource doesn't allow the operation requested. In your case, the request can't be satisfied because something is amiss which doesn't allow it.

这篇关于对于未找到某些链接资源的 PUT 操作，HTTP 404 是否是适当的响应?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！