Should error codes in JSON be integers or strings?

Question

I'm designing a backend webservice, and when an error occurs I'm returning it as a JSON to the frontend. This JSON contains an error code, which the frontend maps to an localized string and shows that to the user.

Should my error codes be strings or integers?

{
  "error": {
    "code": 9900,
    "message": "Invalid ID"
  }
}

OR

{
  "error": {
    "code": "9900",
    "message": "Invalid ID"
  }
}

I'm thinking integers myself, but I'm just wondering if maybe returning fixed length error codes would be more correct, like if I atm have error codes like 9900, 9901, and in the future I wanna send the code 12, would it be correct to send them as "9900", "9901", and "0012", vs 9900, 9901, and 12.

Answer 1

I would go with text. It's OK to have a string where you only use numbers. As a rule of thumb: you should not use integers for things that are not mathematical in nature. That is, if you can do addition or multiplication on the values in a sensible way, then it's a number. Otherwise it's an identifier and you should stick with text. In practice you will probably be fine but using integer types to hold things that are not really numbers can end up being a problem. A classic example is using an integer to store zip-codes i.e. US postal codes.

Answer 2

I'd suggest to a static constant string to both be able to map to i18n and keep expressiveness.

Something like this is nice:

{
 error: 'invalid_id'
}

And you can even scope it to module to locate the origin of the error and avoid overlapping:

{
 error: 'auth.invalid_id'
}

Or, you could also add the http response code inside the object, but that's redundant with the response itself, but might be useful in some case you want to be independent of HTTP and maybe use other type of communication but still use the semantic of it.

{
 error: {
   key: 'auth.invalid_id',
   http_code: 401
 }
}

Answer 3

Do you need to do math on it? if errorCode>9000 etc
Do you need to pass it into anything that expects an integer?
Do you want an early error if you accidentally type an x in the code value?

If you answered no to all of these I can't see a reason why not to use strings.

As for your comment about 0012 vs 12, that's a presentation issue. The backend shouldn't care which you do. But it does presume 9999 is your biggest error code.

Answer 4

Nobody has brought this up but numbers are usually better for i18n. The client can decide what text to display. In many cases the client will have to translate the text depending on the locale, so in most cases this is easily done on the client as there are mechanisms to handle internationalization.

@Bellon's answer also sends the text as well for troubleshooting purposes as someone who is not familiar with number codes can see what the error is.

Answer 5

If you want to send integers, send them as integers. If you have an error code “abcde” then send strings. If “12” and “0012” are different error codes then send strings. But if you the receiver wants integers, send integers.

Answer 6

{
    "code": 9900,
    "message": "Invalid ID"
}

Should be the most appropriate. The standard for numbers requires not to have quotes.

https://www.json.org/

http://www.ecma-international.org/publications/files/ECMA-ST/ECMA-404.pdf

Personally, I'd suggest to follow a pattern for code values similar to the one used by HTTP, so grouping categories of errors (not necessarily grouped by hundreds, but maybe by tens)