RFC-404或400用于在PUT请求中找不到的实体关系 [英] RFC - 404 or 400 for relation of entity not found in PUT request

问题描述

我正在为数据库构建一个REST接口，我遇到了一个问题。

I'm building a REST interface for a database and I've run into a question.

想象一下，我有'Item'表有两列' id'和'user_id'，它是'User'表的外键。

Imagine I have the 'Item' table which has two columns 'id' and 'user_id' which is a foreign key to the 'User' table.

在执行PUT请求（更改项目）时，如果用户表中不存在user_id，则更新将失败。

When doing a PUT request (to change an Item), the update will fail if the 'user_id' doesn't exist in the 'User' table.

我的问题是，这个回复应该是400还是404？我的一部分认为400，因为它是请求者提供的错误数据。但技术上是404，因为无法找到用户资源。

My question is, should this response be a 400 or a 404? Part of me thinks 400, as it's bad data supplied by the requester. But technically a 404 because the user resource can't be found.

有人可以对此有所了解吗？

Can anyone shed some light on this?

提前致谢!! ：）

推荐答案

TLDR

我倾向于 400 因为 - 根据您尝试提供/更改的信息，您不一定希望客户端知道该资源不存在，它只是给出了客户端信息太多了。 404 意味着您没有该资源，如果他们再尝试几次，他们可能会找到一个确实存在的资源。

TLDR

I'm leaning towards a 400 because - depending on the information you're trying to provide/change, you don't necessarily want the client to know that the resource doesn't exist, it's just giving the client a bit too much information. 404 implies that you don't have that resource and if they try a few more times, they might find a resource that does exist.

我认为这个是关于REST状态的一篇很好的小文章，它说（约 400 s）：

I think this is a nice little article about REST states, it says (about 400s):

由于语法格式错误，服务器无法理解该请求。客户不应该在没有修改的情况下重复请求。

The request could not be understood by the server due to malformed syntax. The client SHOULD NOT repeat the request without modifications.

404

<一个href =https://en.wikipedia.org/wiki/List_of_HTTP_status_codes =nofollow>维基百科（不是我使用的是一个明确的来源，但只是说'）说：

404

Wikipedia(Not that i'm using is a definitive source, but just sayin') says:

找不到请求的资源，但将来又可以再次使用
。客户的后续请求是允许的。

The requested resource could not be found but may be available again in the future. Subsequent requests by the client are permissible.

我的2美分*

我猜 404 在传统意义上更有意义，因为它找不到 ，但是，有时你不喜欢我不想让客户知道你的资源不存在，所以你尽量不给它太多的信息，如果我想获得一个资源，我得到一个 404 它告诉我，如果我继续尝试，我将获得一个确实存在的资源，但这个资源不存在。

My 2 cents*

I guess 404 makes a bit more sense in the conventional sense, because it is not found, however, sometimes you don't want to the client to know that your resource doesn't exist, so you try not to give it too much information, If I'm trying to get a resource and I get a 404 It tells me that If I keep trying I'll get a resource that does exist, but this one doesn't.

对于大多数数据，你可以安全地使用 404 ，但如果你发现自己处于一个对数据更加保守的地方，那么可能 400 将会

For most data you can safely use a 404, but if you find yourself in a place where you're trying to be more conservative about your data, then maybe a 400 will do

通常使用 PUT 请求您要改变资源，可能发生的主要错误是未经授权的更改，未找到资源或无效值。显然可能还有其他人，但让我们假设现在就是这种情况。

Usually with PUT requests you're looking to mutate the resource, the main errors that might occur are 'unauthorised change', 'resource not found' or 'invalid value'. Obviously there might be others, but let's assume that this is the case for now.

如果你试图检索一个属性，那么'找不到'，但如果你'试图改变一些不存在的东西我认为'错误请求'或 400 会更有意义。

If you're trying to retrieve an attribute it's 'not found', but if you're trying to change something that doesn't exists I think a 'bad request' or a 400 would make more sense.

*：使用RESTful API，每个人都有自己的解释，我给了你我的：）

祝你好运;）

这篇关于RFC-404或400用于在PUT请求中找不到的实体关系的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！