404 vs 204 on GET, PUT, DELETE Methods

Question

If a request want to get/delete/update to a resource which isn't exist, what do you prefer to return? 204 or 404?

Sample: api/blog/{id} can take that requests: GET, DELETE, PUT and api/blog can take GET and POST.

GET: api/blog returns list of blogs, GET: api/blog/{id} returns single blog,PUT: api/blog/{id} updates single blog and DELETE: api/blog/{id} deletes single blog.

Answer 1

In my opinion the distinction that matters is whether the request ends up successfully or not.

So generally in most of the cases 404 is the way to go.

I would recommend so, because the HTTP response codes are grouped by, let's say, result. source

• Informational responses (100–199)
• Successful responses (200–299)
• Redirects (300–399)
• Client errors (400–499)
• Server errors (500–599)

For example, the process can be like this:

1. The client attempts to DELETE an entity.
2. The entity is not there.
3. This situation can be considered a client error, since deletion of nonexistent entity is being attempted

On 204 again cited from MDN:

The HTTP 204 No Content success status response code indicates that a request has succeeded, but that the client doesn't need to navigate away from its current page.

This might be used, for example, when implementing "save and continue editing" functionality for a wiki site. In this case an PUT request would be used to save the page, and the 204 No Content response would be sent to indicate that the editor should not be replaced by some other page.

Answer 2

If a request want to get/delete/update to a resource which isn't exist, what do you prefer to return? 204 or 404?

"It depends."

If the payload in the response is "a representation containing an explanation of the error situation, and whether it is a temporary or permanent condition", then I'm going to use a 4xx Client Error status code. In the case where I want to draw attention to the target-uri of the request, then I'm going to use 404 Not Found.

On the other hand, if the payload in the response is a representation of the resource, or a representation of a status of a successful action, then I'm going to use some 2xx Successful status code, usually 200 OK.

In particular, if that payload is zero bytes long, I'm normally going to use 200 with Content-Length: 0 rather than 204 No Content. 204 I reserve for those cases where I really want the user agent to stay with the same view. See also 205 Reset Content.

(Part of the lesson here - don't try to guess the meaning of a status code from the accompanying reason phrase. Read the definition.)

---

Whether or not a resource has a "current representation" at any given time is a "resource design" concern. It can make sense to say that this document has a representation even though we've never talked about it before. Maybe that representation is zero bytes long, maybe it has some default representation, like a government form with a bunch of blanks to be filled in later.

For example, a report of activity during some time period might have a current representation even though the time period described by the report is in the future.

---

404 in response to PUT or DELETE is weird.

PUT is semantically close to UPSERT, it's strange to object that you couldn't find a current representation of the resource when I'm asking you to replace it with the representation provided in the payload.

Similarly, DELETE is about decoupling a resource from its implementation. Why report that you can't do it when it has already been done?