I'm currently testing a web service and I have noticed that there is only one error code ever return: 400.

However, the error message return isn't always the same. Here are some examples of the error messages I got:

  • XXX must contain only digits.
  • YYY: This value is not valid.
  • XXX: This value should not be blank.
  • Etc...

So I was wondering if we should use different error code for each message (keeping the HTTP error to 400 but using another code inside the message like 4001, 4002, 4003, etc...). Why would it be a bad idea to do that and why would it be a good one?

Is using only one single error code could make life harder for the front-dev (assuming they have to translate the error message before printing it for clients)? Wouldn't it be simpler for them to have multiple error code? And what would be the drawbacks of having multiple error code instead of one?

  • What other status code would you rather have the server return? Jan 7, 2019 at 9:32
  • @JörgWMittag I don't know, I'm asking if this is a good practice and was thinking, maybe the status code should change with the error message? Jan 7, 2019 at 9:43
  • Those seem validation errors, what makes 400 HTTP status a fairly good code to respond with.
    – Laiv
    Jan 7, 2019 at 9:44
  • 2
    Asking for "good practice" or "bad practice" is off-topic here, because what is "good practice" or "bad practice" is simply the opinion of whomever uses that term. So, in order to make this a good question, you should a) define precisely what you mean by "good practice" and "bad practice", i.e. give objectively measurable unambiguous criteria for "goodness" and "badness", b) explain why, precisely, you think that 400 (Bad Request) is the wrong status code to use, c) tell us what status code you believe would be the right one to use, and d) explain why you think so. Jan 7, 2019 at 9:48
  • @JörgWMittag I edited to try to make it on-topic. Is it better? Jan 7, 2019 at 9:55

1 Answer 1


The key here is not looking at the 400 as a business message' code. This code (the HTTP Status) is specially directed to the HTTP client. By choosing the HTTP status we can make the HTTP Client (sometimes the browser, most of the time the XHR) behave in one way or another. These are codes that operate at a different level than our application. They reach the browser and the browser reacts according to the semantics (these are standards) of these codes, but that's it.

And what would be the drawbacks of having multiple error codes instead of one?

Having a catalogue of codes won't provide any advantage over a simple list of messages if these codes have no purpose. They will, indeed, make the job on the backend a bit harder, if there's a catalogue to maintain that seems to have no purpose. It could be seen as unnecessary complexity or wasted time.

Wouldn't it be simpler for them to have multiple error codes?

What would we be simplifying with a catalogue of codes? Is there anything taking the time of the front-end developers when it comes to handling response messages? Multi-language support? Communication among developers? Between the company and customers? Monitoring? Error solving? Statistics? Debugging? If messages are addressed to regular users. What are they supposed to do with these codes?

Most of the time, a list of messages or a list of messages + the name of the field/business rule involved is enough. Codes might be seen as annoying technical details by tech-savvy users.

Codes are ok and can be useful, but they are if they solve a real problem.

  • "If we couple the client-side and error codes tightly ..." You have to, each time backend API changes, you need to let the frontend know, that's no way around anyway. Feb 22, 2022 at 15:36
  • You are right. The question is not answered properly the question because I misunderstood what "code" was the OP referring to. I will edit to answer accordingly. thank you for the head up
    – Laiv
    Feb 22, 2022 at 16:49

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.