HTTP Bad Request (400) vs Not Found (404): Which status code to use?

REST API developers might be tempted to use a 400 Bad Request error when a resource does not exist. After all, the client made a bad request, right?

HTTP error codes in the 4xx range all indicate that client made a mistake. However, when a client makes a request to a resource that does not exist, the server should respond with a 404 Not Found error.

404 Not Found is a more descriptive status code to use because it tells the client that they are trying to access a resource that does not exist.

Bad Request (400) vs Not Found (404)

The main difference between a "400 Bad Request" and "404 Not Found" status codes is that Bad Request indicates incorrect syntax, while Not Found indicates a missing resource. Moreover, bad requests should not be repeated, while not found requests can be repeated. The "404 Not Found" responses are cacheable, while "400 Bad Request" are not.

A 400 Bad Request error indicates that the server was unable to understand the request. This can be caused by incorrect syntax or invalid characters in the URL.

A 404 Not Found error means that the server was unable to find the requested resource. This can happen if the URL is typed incorrectly, or if the page has been deleted.

While both of these errors can be frustrating, a 404 Not Found error is generally more forgiving because it means that the resource could not be found. In contrast, a 400 Bad Request error suggests that there is something wrong with the request itself, which may require further investigation.

RFC7231 6.5.1 Explaining 400 Bad Request — RFC7231 6.5.1

Why we shouldn't repeat requests that return the 400 status code?

We shouldn't repeat requests that return "400 Bad Requests" errors because that error indicates incorrect syntax. So no matter how many times we repeat the request, the result will be the same: a 400 Bad Request error. In addition, repeating a request can also cause performance problems for the server, so it's best to avoid doing it.

On the other hand, you can repeat requests that return "404 Not Found" because the resource might become available. Because of the possibility that resource becomes available, the "404 Not Found" responses are cacheable.

FAQ: Bad Request vs Not Found

What is the difference between the HTTP Bad Request (400) and Not Found (404) status codes?

The HTTP Bad Request (400) status code indicates that the request made by the client was invalid or cannot be understood by the server. This could be due to a variety of factors, such as a malformed request syntax, invalid request message framing, or deceptive request routing. On the other hand, the HTTP Not Found (404) status code indicates that the requested resource could not be found on the server. This could be because the resource has been removed or moved, or because the client has provided an incorrect or outdated URL.

When should I use the HTTP Bad Request (400) status code?

You should use the HTTP Bad Request (400) status code when the client has requested that the server cannot understand or process. This could be due to a variety of issues, such as a malformed request syntax, invalid request message framing, or deceptive request routing.

When should I use the HTTP Not Found (404) status code?

You should use the HTTP Not Found (404) status code when the requested resource cannot be found on the server. This could be because the resource has been removed or moved, or because the client has provided an incorrect or outdated URL.

Can I use the HTTP Bad Request (400) status code for resources that have been removed or moved?

No, you should not use the HTTP Bad Request (400) status code for resources that have been removed or moved. Instead, you should use the HTTP Not Found (404) status code in these cases.

Can I use the HTTP Not Found (404) status code for invalid or malformed requests?

No, you should not use the HTTP Not Found (404) status code for invalid or malformed requests. Instead, you should use the HTTP Bad Request (400) status code in these cases.

See also:

Last modified on: Dec 18, 2022