REST API design error response
Hi, I have a question about API design.
When my service receives an invalid POST body, I currently return only an HTTP 400 with no additional content. My reasoning is that normal users always go through my frontend, which already performs client-side validation, so they should never encounter this error.
While reviewing other APIs, I noticed that they often return extra information. What do you recommend?
1 Reply
If the error is genuinely a 400 issue (i.e. the request is malformed, or doesn't contain the correct data needed) then it's a good idea to return some information to the user about why that has happened, so that they can fix it and try again. Your client side validation should catch this, but if things change then it may slip through the net.
With API design, you always want to perform all the validation and authentication checks that are necessary on the server. It's a good idea to always assume the request coming in could be / is from a malicious attacker.
The 400 response code is for when the request is incorrect. It doesn't (and shouldn't) account for other issues like being unauthorised (401), not finding resources (404) or random server errors (500).