CODEWITHSUNDEEP
web-servicesrest
Vineet Singla
Vineet Singla

Reputation: 1677

Response code 400 or 403 for POST Restful APIs

I am designing a POST Restful API, where I have a situation that I have to authorize a user based upon one of the element provided in the request body. For eg.

{
division : "1",
name : "MyName",
address:{
no : 123,
street : "abc",
pincode : 222111
}
....
}

So the user making POST request should be authorized to work on division 1. I cannot authorize the user without getting request body.

Also to validate some of the attributes I have to make heavy DB calls in the DB , for eg, to check the above address has a valid value of pincode.

So My question is how should I return the error codes to the user -

  1. [EDIT]If division is not valid(something that doesnt exist in system) in the request - 400 or 403 ?
  2. If division is provided, but user is not authorized and pincode is invalid - 400 for invalid pincode or 403 ?
  3. What should be the error code if pincode is mandatory attribute and is not provided in the request. Should I first check 403 and then 400 or reverse ?

Basically which error code to proceed the other ?

Also is it okay to do something like :

400 – request is bad, syntactically (division/pincode or other mandatory values not provided)
403 – authorize user
400 – request is bad, data specific validation (heavier operation, requiring to hit DB)

[EDIT] we preferred not to use 422 error code

Upvotes: 12

Views: 38719

Answers (2)

jbarrueta
jbarrueta

Reputation: 5185

I think you're in the right track. Assuming that every request is being authenticated via (http authorization header)

  1. Returning 400, on missing data is OK, and furthermore you can add error response body explaining what was the reason for the Client request not being accepted (in this case the missing division).

  2. Returning 403, is OK if the client making the request is not authorized to interact with the resource (in this case the division).

  3. You must validate first if the Client is authorized to interact with the resource, so 403 must be sent first, and if a required field is missing you can treat it as a 400 (with a proper explanation).

In case the Client is not authenticated, the correct response should be 401, but like I said before, 1) and 2) in my response are assuming that the Clients are authenticated against the server.

Hope it helps,

Jose Luis

Upvotes: 1

Tim
Tim

Reputation: 43354

When in doubt, just take a look at the RFC

400 Bad Request

The request could not be understood by the server due to malformed syntax. The client SHOULD NOT repeat the request without modifications.

403 Forbidden

The server understood the request, but is refusing to fulfill it. Authorization will not help and the request SHOULD NOT be repeated. If the request method was not HEAD and the server wishes to make public why the request has not been fulfilled, it SHOULD describe the reason for the refusal in the entity. If the server does not wish to make this information available to the client, the status code 404 (Not Found) can be used instead.

If division is not provided in the request - 400 or 403?

I don't think either apply. The syntax -although it's missing some data- is not malformed.
Also 403 seems incorrect because of reasons mentioned above in the quote: authorization will not help etc.

How about 422 Unprocessable Entity?

422 Unprocessable Entity (WebDAV; RFC 4918)

The request was well-formed but was unable to be followed due to semantic errors.

That is what I usually use in situations like this.

If division is provided, but user is not authorized and pincode is invalid - 400 for invalid pincode or 403?

Again, I don't think either 400 or 403 make a good case here. Specifically for this situation, 401 exists

401 Unauthorized

Similar to 403 Forbidden, but specifically for use when authentication is required and has failed or has not yet been provided. The response must include a WWW-Authenticate header field containing a challenge applicable to the requested resource. See Basic access authentication and Digest access authentication.

Upvotes: 14

Related Questions