问题
When designing the errors of a REST API seems to be a good practice to follow standard HTTP codes (4XX and 5XX) and to include a body (XML/JSON) with:
- brief message
- description
- code
My question is ... shall these messages be internationalized?
I tend to think that showing a message to the client is client side responsability, and those API errors should be considered as an agreement (format, and code field) between the client app and the API but shall not be considered by default as perfectly suited to be exposed to the client directly, so formatting the final message "Ooops ... something was wrong" shall be done at client side. In other case i can see API deployments because P.O. needs to change "Oops" to "Uups" and things like that, that seems totally like something related to the look and feel of the client app IMHO.
回答1:
You are right, most of the time you won't need to expose the REST exceptions to the client, since REST errors are too technical.
Still there are applications that will choose to let the user "drill into the technical error" - but even if this is the case I believe that the end user understands that now we are in the "techincal detials" area and won't expect translation of the message (+ translating technical messages simply won't sound good in other languages except English)
回答2:
I'd say if your whole API is internationalized and the client can choose the language through the Accept-Language header, then the API errors should be internationalized as well.
来源：https://stackoverflow.com/questions/29242626/shall-rest-api-error-messages-be-internationalized