CODEWITHSUNDEEP
apihttpspecifications
user2824512
user2824512

Reputation: 105

HTTP 400 vs HTTP 404 for a malformed URI api request

So imagine we have an endpoint called /guest/{guestId}. This endpoint has a GET function where if you provide it a guestId it will return an object with all of the guest information.

The question is what should be returned in each of these scenarios -

guestId = "" leading to /guest/
guestId = "invalidId" leading to /guest/invalidId

The HTTP 1.1 documentation seems to leave room open for either in terms of passing an invalid ID but suggests a 404 when the guestId is blank. For an invalid ID, it's technically hitting the endpoint but just giving it malformed syntax which points towards a 400 but at the same time provides the server with an invalid URI which points to a 404.

What is factually and not opinion-basedly correct?

Upvotes: 5

Views: 1887

Answers (1)

Evert
Evert

Reputation: 99553

There's no room for interpretation here. The resource at /guest/invalidId doesn't exist and should return a 404.

The request itself wasn't really 'malformed' in anyway, it just used a uri that was pointing to a non-existent resource. It's malformed, maybe in the perspective of your specific application (it's not a valid id), but it is not from the perspective of the HTTP protocol.

As a general rule this might help as well:

When you want to emit an error to a client, and the client is responsible. You'll want to emit an error in the 400-499 range. If you can't find a good specific error to meet your specific error condition, only then you'll really want to use 400, as in practice it's kind of used as a status code when nothing else really is fitting.

Upvotes: 6

Related Questions