REST API 404: URI错误，还是缺少资源？
我正在构建一个REST API，但我遇到了一个问题。
似乎设计REST API的公认实践是，如果请求的资源不存在，则返回404。
然而，对我来说，这增加了不必要的歧义。HTTP 404更传统地与坏的URI相关联。所以实际上我们是在说“要么你到了正确的地方，但是那个特定的记录不存在，或者在互联网上没有这样的位置！我真的不确定是哪一个……”
考虑以下URI：
http://mywebsite/api/user/13如果我得到一个404，是不是因为用户13不存在？或者是因为我的URL应该是：
http://mywebsite/restapi/user/13在过去，如果记录不存在，我只会返回一个带有HTTP 200 OK响应代码的空结果。它很简单，在我看来非常干净，即使它不一定是被接受的实践。但是有没有更好的方法呢？
回答 10
Stack Overflow用户
发布于 2012-03-30 01:52:24
404只是HTTP响应代码。最重要的是，您可以提供一个响应体和/或其他头，其中包含开发人员将看到的更有意义的错误消息。
Stack Overflow用户
发布于 2012-03-31 00:02:34
如果资源不存在，则使用 404 。不返回正文为空的 200 。
这类似于编程中的空字符串和空字符串(例如undefined ""**) in .虽然非常相似，但肯定是有区别的。**
404意味着该URI不存在任何东西(就像编程中的未定义变量一样)。返回带有空体的200意味着那里确实存在一些东西，并且现在只是空的(就像编程中的空字符串一样)。
404并不意味着它是一个“糟糕的URI”。有一些专门针对URI错误的HTTP码(例如414 Request-URI Too Long)。
Stack Overflow用户
发布于 2012-03-30 06:07:19
与大多数事情一样，“视情况而定”。但对我来说，您的实践并不糟糕，并且本身并不违反HTTP规范。然而，让我们把一些事情弄清楚。
首先，URI应该是不透明的。即使它们对人来说不透明，它们对机器也是不透明的。换句话说，http://mywebsite/api/user/13，http://mywebsite/restapi/user/13之间的差异与http://mywebsite/api/user/13和http://mywebsite/api/user/14之间的差异是相同的，即不同的是不同的周期。因此，404将完全适用于http://mywebsite/api/user/14 (如果没有这样的用户)，但不一定是唯一合适的响应。
您也可以返回一个空的200响应，或者更明确地返回一个204 (No Content)响应。这将向客户端传达一些其他信息。这意味着由http://mywebsite/api/user/14标识的资源没有内容或本质上什么都不是。这确实意味着有这样的资源。然而，这并不一定意味着您声称有一些用户持久化在id为14的数据存储中，这是您的私人问题，而不是发出请求的客户端的问题。因此，如果以这种方式对您的资源进行建模是有意义的，请继续。
给你的客户提供信息会有一些安全隐患，这会让他们更容易猜出合法的URI。在未命中时返回200而不是404可能会给客户一个线索，表明至少http://mywebsite/api/user部分是正确的。恶意客户端可能只会不断尝试不同的整数。但对我来说，恶意客户端无论如何都能猜到http://mywebsite/api/user部分。一个更好的补救方法是使用UUID，即http://mywebsite/api/user/3dd5b770-79ea-11e1-b0c4-0800200c9a66比http://mywebsite/api/user/14更好。这样做，你可以使用你的技术返回200，而不会放弃太多。
https://stackoverflow.com/questions/9930695
复制相似问题