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

问题描述

想象一下REST Web服务，您可以在其中将项目添加到某种类型的容器中。例如，假设我们可以将参与者＃789添加到事件＃456，如下所示：

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

如果事件＃456或与会者＃789不存在，返回HTTP 404是否正确（以及解释问题的详细错误有效负载，例如 {error：{message：事件456不存在，代码：404}} ？

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" } }?

同样，如果我创建一些引用另一个对象的新内容，但另一个对象不存在？例如，想象一下我在位置＃123创建一个事件

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... }

如果位置＃123不存在，返回404也是正确的（以及响应中的详细信息） ？如果没有，那么什么是合适的 - 只需400？

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?

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

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

9.6 PUT ...如果无法使用Request-URI创建或修改资源，则会出现相应的错误响应应该给出反映问题性质的信息

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

所以这似乎是对404回应的好投票。但是由于某些原因我无法完全按下手指，用404响应PUT（或POST）对我来说似乎很奇怪......也许是因为404意味着无法找到资源，但在此case我们的资源实际上是两个其他资源之间的联系，它是无法找到的两个资源之一。

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.

不要太担心我的确切资源这里的例子 - 它们是为了说明这一点。主要问题是：404对PUT操作的适当响应是否因为找不到链接资源而失败？

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?

如果您可以指向引用，那将是非常好的 - - 我很难找到任何进入这个细节水平并且也足够可信的东西。特别是关于REST API设计中资源关系的处理。

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.

更新思维我在想第一个例子应该返回404，第二不应该。原因在于，在第一种情况下，我们添加的资源使用事件456和参与者789作为它的复合主键;第二个案例位置只是一个外键。在第二种情况下，应该返回错误，但不是404 - 可能是412 Precondition Failed或者可能只是400 Bad Request。思考？

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?

推荐答案

有一些4xx HTTP状态代码。最有可能是404或409：

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

404 Not Found

服务器未找到与有效请求URI匹配的任何内容。
没有说明条件是暂时的还是
永久性的。如果服务器
通过一些内部可配置机制知道旧的
资源永久不可用且没有转发地址，则应该使用410（Gone）状态代码。
当服务器不希望
明确说明请求被拒绝的原因，或者没有其他
响应适用时，通常会使用此状态代码。

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冲突

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

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.

最有可能发生冲突以响应PUT请求。对于
示例，如果正在使用版本控制并且表示为
PUT包含对资源的更改与
早期（第三方）请求所产生的更改，则服务器可能会使用409
回复表示无法完成请求。在这个
的情况下，响应表示可能包含两个版本之间
差异的列表。

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.

其中任何一个都适合，但我想我会选择409. 404用于 URI not found 但409表示资源的当前状态不允许请求的操作。在您的情况下，请求无法满足，因为某些东西是不允许的。

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.

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