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


当前回答

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

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

其他回答

404只是HTTP响应代码。在此基础上,您可以提供一个响应体和/或其他带有开发人员将看到的更有意义的错误消息的报头。

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

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

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

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

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

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

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

对于这个场景,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抛出的正确消息