统一资源标识符是指向资源的唯一指针。格式较差的URI不指向资源，因此对其执行GET操作将不会返回资源。404表示服务器没有找到任何与请求uri匹配的内容。如果你输入了错误的URI或坏的URI，这就是你的问题，也是你无法访问资源的原因，无论是HTML页面还是IMG。

404 Not Found在技术上意味着uri当前没有映射到某个资源。在您的示例中，我解释了对http://mywebsite/api/user/13的请求，该请求返回404，以暗示此url从未映射到资源。对于客户来说，这应该是谈话的结束。

To address concerns with ambiguity, you can enhance your API by providing other response codes. For example, suppose you want to allow clients to issue GET requests the url http://mywebsite/api/user/13, you want to communicate that clients should use the canonical url http://mywebsite/restapi/user/13. In that case, you may want to consider issuing a permanent redirect by returning a 301 Moved Permanently and supply the canonical url in the Location header of the response. This tells the client that for future requests they should use the canonical url.

所以从本质上讲，听起来答案可能取决于请求是如何形成的。

如果根据对http://mywebsite/restapi/user/13的请求，所请求的资源构成URI的一部分，而用户13不存在，那么404可能是合适的和直观的，因为URI代表不存在的用户/实体/文档等。对于使用GUID http://mywebsite/api/user/3dd5b770-79ea-11e1-b0c4-0800200c9a66和上面的api/restapi参数的更安全的技术，情况也是如此。

However, if the requested resource ID was included in the request header [include your own example], or indeed, in the URI as a parameter, eg http://mywebsite/restapi/user/?UID=13 then the URI would still be correct (because the concept of a USER does exits at http://mywebsite/restapi/user/); and therefore the response could reasonable be expected to be a 200 (with an appropriately verbose message) because the specific user known as 13 does not exist but the URI does. This way we are saying the URI is good, but the request for data has no content.

就我个人而言，200还是感觉不对(尽管我之前也说过)。例如，当发送不正确的ID时，200响应代码(没有详细响应)可能导致不调查问题。

A better approach would be to send a 204 - No Contentresponse. This is compliant with w3c's description *The server has fulfilled the request but does not need to return an entity-body, and might want to return updated metainformation.*1 The confusion, in my opinion is caused by the Wikipedia entry stating 204 No Content - The server successfully processed the request, but is not returning any content. Usually used as a response to a successful delete request. The last sentence is highly debateable. Consider the situation without that sentence and the solution is easy - just send a 204 if the entity does not exist. There is even an argument for returning a 204 instead of a 404, the request has been processed and no content has been returned! Please be aware though, 204's do not allow content in the response body

来源

http://en.wikipedia.org/wiki/List_of_HTTP_status_codes 1. http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html

由于这个讨论似乎能够在时间结束时幸存下来，我将抛出JSON:API规范

404未找到 服务器在处理获取不存在的单个资源的请求时必须响应404 Not Found，除非请求保证200 OK响应并以null作为主要数据(如上所述)。

HTTP/1.1 200 OK
Content-Type: application/vnd.api+json

{
  "links": {
    "self": "http://example.com/articles/1/author"
  },
  "data": null
}

也请看看这个Stackoverflow问题

和大多数事情一样，“视情况而定”。但对我来说，您的做法并不坏，并且没有违背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(如果没有这样的用户)，但不一定是唯一合适的响应。

You could also return an empty 200 response or more explicitly a 204 (No Content) response. This would convey something else to the client. It would imply that the resource identified by http://mywebsite/api/user/14 has no content or is essentially nothing. It does mean that there is such a resource. However, it does not necessarily mean that you are claiming there is some user persisted in a data store with id 14. That's your private concern, not the concern of the client making the request. So, if it makes sense to model your resources that way, go ahead.

There are some security implications to giving your clients information that would make it easier for them to guess legitimate URI's. Returning a 200 on misses instead of a 404 may give the client a clue that at least the http://mywebsite/api/user part is correct. A malicious client could just keep trying different integers. But to me, a malicious client would be able to guess the http://mywebsite/api/user part anyway. A better remedy would be to use UUID's. i.e. http://mywebsite/api/user/3dd5b770-79ea-11e1-b0c4-0800200c9a66 is better than http://mywebsite/api/user/14. Doing that, you could use your technique of returning 200's without giving much away.

统一资源标识符是指向资源的唯一指针。格式较差的URI不指向资源，因此对其执行GET操作将不会返回资源。404表示服务器没有找到任何与请求uri匹配的内容。如果你输入了错误的URI或坏的URI，这就是你的问题，也是你无法访问资源的原因，无论是HTML页面还是IMG。