想象一下REST Web服务，您可以在其中向某种类型的容器添加项目。例如，假设我们可以将参与者＃789添加到事件＃456中，如下所示：
PUT http://..../api/v1/events/456/attendees/789
如果事件＃456或与会者＃789不存在，返回HTTP 404是否正确（以及解释问题所在的详细错误有效负载，例如{ "error" : { "message" : "Event 456 does not exist" , "code" : "404" } }？
同样，如果我创建一个引用另一个对象的新东西，但另一个对象不存在呢？例如，假设我在位置＃123
创建一个事件PUT http://..../api/v1/event
{ "location": 123, "name": "Party", "date": "2012-05-23", ...etc... }
如果位置＃123不存在，返回404（以及响应中的详细信息）是否正确？如果没有，那么什么是恰当的 - 只有400？
根据HTTP 1.1规范http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html
9.6 PUT ...如果无法使用Request-URI创建或修改资源，则应该给出适当的错误响应，以反映问题的性质
所以这对于用404响应似乎是一个很好的投票。然而由于某种原因我不能完全放下手指，用404响应PUT（或POST）似乎很奇怪对我来说......也许是因为404意味着无法找到资源，但在这种情况下，我们的资源实际上是两个其他资源之间的联系，而且它是无法找到的两个资源之一。
不要太担心我的确切例子 - 它们是为了说明这一点。主要问题是：404对PUT操作的适当响应是否因为找不到链接资源而失败？
如果你可以指出参考资料那将是非常好的 - 我很难找到任何进入这个细节水平并且也足够可信的东西。特别是关于REST API设计中资源关系的处理。
更新思维我在想第一个例子应该返回404，第二个例子不应该返回404。原因在于，在第一种情况下，我们要添加的资源使用事件456和参与者789作为它的复合主键;第二个案例位置只是一个外键。在第二种情况下，应该返回错误，但不是404 - 可能是412 Precondition Failed或者可能只是400 Bad Request。思考？
答案 0 :(得分：16)
有许多4xx HTTP status codes。最有可能是404或409：
404 Not Found
服务器未找到与有效请求URI匹配的任何内容。 没有说明该病症是暂时的还是 常驻。如果服务器应该使用410（Gone）状态代码 通过一些内部可配置的机制，知道一个旧的 资源永久不可用，没有转发地址。 此状态代码通常在服务器不希望时使用 明确说明请求被拒绝的原因，或者没有其他请求 回应是适用的。
409冲突
由于与当前的冲突，请求无法完成 资源的状态。此代码仅在以下情况下允许 预计用户可能能够解决冲突 并重新提交请求。响应机构应该包括足够的内容 用户识别冲突根源的信息。 理想情况下，响应表示将包含足够的信息 为用户或用户代理解决问题;但是，那可能 不可能，也不是必需的。
最有可能发生冲突以响应PUT请求。对于 如果正在使用版本控制并且表示正在使用 PUT包括与资源相冲突的资源变更 在早期（第三方）请求中，服务器可能使用409 响应表明它无法完成请求。在这 例如，响应表示可能包含一个列表 两个版本之间的差异。
其中任何一个都适合，但我想我会选择409. 404用于 URI not found 但409表示资源的当前状态不允许请求的操作。在您的情况下，请求无法满足，因为有些东西是不允许的。