HTTP GET Request Status 204 Vs 404

2019-02-03 12:00发布

问题:

I have 2 resources User and Album. An user has a list of albums. To get albums there are 2 REST API.

  1. user/{userId}/albums/{albumId} get album by albumId if not found return 404
  2. user/{userId}/albums get all albums by userId . In this case if a user has no album then what is the status code 204 or 404?

回答1:

Is the absence of any album really seen as an error? Assuming the albums are returned as a JSON array, the common response to such a situation would be a HTTP 200 with an empty array as the body.

Returning 404 signals that the resource doesn't exist, kind of saying that it isn't even possible to ask for the list of albums for this particular user. But in fact, it's possible to successfully return the list of albums, it's just that the list is empty. It doesn't seem at all exceptional to me. This is completely in contrast to retrieval of one specific album using an ID that doesn't exist (using your other endpoint); in such a situation a 404 is correct.

While a 204 seems better than a 404, because it at least tells the client that the requrest was successful but had no content, it's intention is not really to be used to signal a "successful absence". Rather, it signals that the resource DOES exist but for some reason the server chose not to include the resource in the response body - for example the purpose of the request could have been to simply pass back some headers to the client.

A 204 can also be used as a response to a POST request where some action was carried out by the server without necessarily creating any new resource (which would have implied a 201 CREATED), or where it's for some other reason not relevant to return any resource.

I think it's clear that what you need is a

GET /user/xxx/albums

HTTP/1.1 200 OK

[]


回答2:

Error Code 404

The web site hosting server will typically generate a "404 Not Found" web page when a user attempts to follow a broken or dead link.

Return Code 204

The server has fulfilled the request but does not need to return an entity-body.

Conclusion

You obviously need to raise a 204 error. If you use the 404 one, user may be disturbed. More, you use 404 when the targeted album doesn't exist. Use 404 for both 1 and 2 is in lack of logic.



回答3:

Here is what the RFC2616 that defines the HTTP protocol says about Status-codes:

The first digit of the Status-Code defines the class of response. The last two digits do not have any categorization role. There are 5 values for the first digit:

  - 1xx: Informational - Request received, continuing process

  - 2xx: Success - The action was successfully received,
    understood, and accepted

  - 3xx: Redirection - Further action must be taken in order to
    complete the request

  - 4xx: Client Error - The request contains bad syntax or cannot
    be fulfilled

  - 5xx: Server Error - The server failed to fulfill an apparently
    valid request

In your case, the request was successful, but there are no albums to show, so you definitely should use a status from the 2xx category.

Here is what the RFC says about the 204 status:

10.2.5 204 No Content

The server has fulfilled the request but does not need to return an entity-body, and might want to return updated metainformation. The response MAY include new or updated metainformation in the form of entity-headers, which if present SHOULD be associated with the requested variant.

If the client is a user agent, it SHOULD NOT change its document view from that which caused the request to be sent. This response is primarily intended to allow input for actions to take place without causing a change to the user agent's active document view, although any new or updated metainformation SHOULD be applied to the document currently in the user agent's active view.

The 204 response MUST NOT include a message-body, and thus is always terminated by the first empty line after the header fields.

The RFC states that the 204 is primarily intended to allow inputs, so you shouldn't use this one. I would use the 200 in this case.