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

这是一个非常老的帖子，但我也面临着类似的问题，我想与你们分享我的经验。

我正在用rest api构建微服务架构。我有一些rest GET服务，他们根据请求参数从后端系统收集数据。

我遵循其余的API设计文档，当没有符合查询条件的数据(例如零记录被选中)时，我向客户端发送了带有完美JSON错误消息的HTTP 404。

当没有数据要发送回客户端时，我准备了一个完美的JSON消息，包含内部错误代码等，以通知客户端“未找到”的原因，并将其与HTTP 404一起发送回客户端。这很好。

后来我创建了一个rest API客户端类，这是一个容易隐藏HTTP通信相关代码的助手，当我从我的代码调用我的rest API时，我一直使用这个助手。

但我需要编写令人困惑的额外代码，因为HTTP 404有两个不同的功能:

当rest API在给定的url中不可用时，真正的HTTP 404将由运行rest API应用程序的应用服务器或web服务器抛出 当数据库中没有数据时，客户端根据查询的where条件返回HTTP 404。

重要:我的rest API错误处理程序捕获后端服务中出现的所有异常，这意味着在任何错误的情况下，我的rest API总是返回一个带有消息详细信息的完美JSON消息。

这是我的客户端助手方法的第一个版本，它处理两个不同的HTTP 404响应:

public static String getSomething(final String uuid) {
    String serviceUrl = getServiceUrl();
    String path = "user/" + , uuid);
    String requestUrl = serviceUrl + path;
    String httpMethod = "GET";

    Response response = client
            .target(serviceUrl)
            .path(path)
            .request(ExtendedMediaType.APPLICATION_UTF8)
            .get();

    if (response.getStatus() == Response.Status.OK.getStatusCode()) {
        // HTTP 200
        return response.readEntity(String.class);
    } else {
        // confusing code comes here just because
        // I need to decide the type of HTTP 404...

        // trying to parse response body
        try {
            String responseBody = response.readEntity(String.class);
            ObjectMapper mapper = new ObjectMapper();
            ErrorInfo errorInfo = mapper.readValue(responseBody, ErrorInfo.class);

            // re-throw the original exception
            throw new MyException(errorInfo);

        } catch (IOException e) {
            // this is a real HTTP 404
            throw new ServiceUnavailableError(response, requestUrl, httpMethod);
        }

    // this exception will never be thrown
    throw new Exception("UNEXPECTED ERRORS, BETTER IF YOU DO NOT SEE IT IN THE LOG");
}

但是，因为我的Java或JavaScript客户端可以接收两种类型的HTTP 404，我需要以某种方式检查响应的主体，以防HTTP 404。如果我可以解析响应体，那么我肯定我得到了一个响应，其中没有数据要发送回客户端。

如果我不能解析响应，这意味着我从web服务器(而不是从其余API应用程序)得到了一个真正的HTTP 404。

这太令人困惑了，客户端应用程序总是需要做额外的解析来检查HTTP 404的真正原因。

说实话，我不喜欢这个解决方案。这是令人困惑的，需要向客户端添加额外的狗屁代码。

因此，在这两个不同的场景中，我决定不使用HTTP 404，而是执行以下操作:

我不再在我的应用程序中使用HTTP 404作为响应HTTP代码。 我将使用HTTP 204 (No Content)而不是HTTP 404。

在这种情况下，客户端代码可以更优雅:

public static String getString(final String processId, final String key) {
    String serviceUrl = getServiceUrl();
    String path = String.format("key/%s", key);
    String requestUrl = serviceUrl + path;
    String httpMethod = "GET";

    log(requestUrl);

    Response response = client
            .target(serviceUrl)
            .path(path)
            .request(ExtendedMediaType.APPLICATION_JSON_UTF8)
            .header(CustomHttpHeader.PROCESS_ID, processId)
            .get();

    if (response.getStatus() == Response.Status.OK.getStatusCode()) {
        return response.readEntity(String.class);
    } else {
        String body = response.readEntity(String.class);
        ObjectMapper mapper = new ObjectMapper();
        ErrorInfo errorInfo = mapper.readValue(body, ErrorInfo.class);
        throw new MyException(errorInfo);
    }

    throw new AnyServerError(response, requestUrl, httpMethod);
}

我认为这能更好地解决这个问题。

如果你有更好的解决方案，请与我们分享。

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

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

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

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

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

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

和大多数事情一样，“视情况而定”。但对我来说，您的做法并不坏，并且没有违背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.