Should REST API error messages be internationalized?

When developing REST API errors, it seems good to follow standard HTTP codes (4XX and 5XX) and include the body (XML / JSON) with:

  • short message
  • Description
  • the code

My question is: should these messages be internationalized?

I am inclined to think that displaying the message to the client is the responsibility on the client side, and these API errors should be considered as an agreement (format and code field) between the client application and the API, but should not be considered by default as ideal for direct contact with the client, therefore formatting of the final message "Ooops ... something was wrong" should be done on the client side. In another case, I can see the API deployment because PO needs to change “Oops” to “Uups” and the like, which looks like something similar to the look of the IMHO client application.

+5
source share
2 answers

You are correct, most of the time you do not need to throw REST exceptions to the client, because REST errors are too technical.

Nevertheless, there are applications that will allow the user to “deploy a technical error” - but even so, I believe that the end user understands that we are now in the “techincal detials” area and won’t wait for the message to be translated (+ translation technical messages just won't sound good in languages ​​other than English)

+3
source

I would say if your entire API is internationalized and the client can select a language through the Accept-Language header, then the API errors should also be internationalized.

+2
source

Source: https://habr.com/ru/post/1216023/


All Articles