Home > Blockchain >  HTTP GET Request Params - which error code? 400 vs 404 vs 422
HTTP GET Request Params - which error code? 400 vs 404 vs 422

Time:05-30

I've read a lot of questions about 400 vs 422, but they are almost for HTTP POST requests for example this one: 400 vs 422 response to POST of data.

I am still not sure what should I use for GET when the required parameters are sent with wrong values. Imagine this scenario:

  • I have the endpoint /searchDeclaration, with the parameter type.
  • My declarations have 2 types: TypeA and TypeB.

So, I can call this endpoint like this: /searchDeclaration?type=TypeA to get all TypeA declarations.

What error should I send when someone calls the endpoint with an invalid type? For example: /searchDeclaration?type=Type123

Should I send 400? I am not sure it is the best code, because the parameter is right, only the value is not valid.

The 422 code looks like it is more suitable for POST request.

EDIT: After some responses I have another doubt. The /searchDeclaration endpoints will return the declaration for the authenticated user. TypeA and TypeB are valid values, but some users don't have submitted a TypeB declaration, so when they call /searchDeclaration?type=TypeB which error should I send? Returning 404 does not seem right because the URI is correct, but that user does not have a declaration for that value yet. Am I overthinking this?

CodePudding user response:

If the URI is wrong, use 404 Not Found.

The 404 (Not Found) status code indicates that the origin server did not find a current representation for the target resource

The target resource is, as one might expect, identified by the target URI.

Aside from the semantics of the response, 404 indicates that the response is cacheable - meaning that general purpose caches will know that they can re-use this response to future requests


I am not sure it is the best code, because the parameter is right, only the value is not valid.

The fact that this URI includes parameters and values is an implementation detail; something that we don't care about at the HTTP level.

Casually: 404 means "the URI is spelled wrong"; but doesn't try to discriminate which part(s) of the URI have errors. That information is something that you can include in the body of the response, as part of the explanation of the error situation.

CodePudding user response:

There are two options, it all depends on your 'type' variable.

  1. If 'type' is an ENUM, which only allows 'typeA' and 'typeB', and your client sends 'type123', the service will respond with a '400 Bad Request' error, you don't need to check. In my opinion, this should be ideal, since if you need to add new 'type's in the future, you will only have to add them in the ENUM, instead of doing 'if-else' inside your code to check them all.

  2. In case the 'type' variable is a String, the controller will admit a 'type123' and you should be the one to return an error, since the client request is not malformed, but rather it is trying to access a resource that does not exist.

In this case, you can return a 404 Not Found error, (that resource the client is filtering by cannot be found), or a 422 error as you say, since the server understands the request, but is not able to process it.

  • Related