我正在构建一个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响应代码的NULL结果。它很简单,在我看来非常干净,即使它不一定是公认的实践。但是有没有更好的办法呢?


当前回答

统一资源标识符是指向资源的唯一指针。格式较差的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

如果资源不存在,请使用404。不要返回一个空的200。

这类似于未定义vs空字符串(例如。"")。虽然非常相似,但绝对有区别。

404表示该URI上不存在任何东西(就像编程中未定义的变量一样)。返回200且主体为空意味着这里确实存在某些东西,并且某些东西现在只是空的(就像编程中的空字符串)。

404并不意味着它是一个“坏URI”。有一些特殊的HTTP代码用于处理URI错误(例如414 Request-URI Too Long)。

对于这个场景,HTTP 404是来自REST API的响应的响应代码 比如400,401,404,422不可处理实体

使用异常处理来检查完整的异常消息。

try{
  // call the rest api
} catch(RestClientException e) {
     //process exception
     if(e instanceof HttpStatusCodeException){
        String responseText=((HttpStatusCodeException)e).getResponseBodyAsString();
         //now you have the response, construct json from it, and extract the errors
         System.out.println("Exception :" +responseText);
     }

}

这个异常块为您提供由REST API抛出的正确消息

这篇古老但优秀的文章……http://www.infoq.com/articles/webber-rest-workflow是这么说的…

404 Not Found——服务太懒惰(或者太安全)了,不能给我们一个请求失败的真实原因,但是不管是什么原因,我们都需要处理它。