REST API错误消息是否应国际化？ [英] Shall REST API error messages be internationalized?

问题描述

在设计REST API的错误时，遵循标准HTTP代码（4XX和5XX）并包含带有以下内容的正文（XML / JSON）似乎是一个好习惯：

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:

• 简短消息


• 描述


• 代码

我的问题是...这些消息是否应该被国际化？

My question is ... shall these messages be internationalized?

我倾向于认为向客户显示消息就是客户方面的责任，这些API错误应视为客户端应用程序与API之间的协议（格式和代码字段），但默认情况下不应认为它们完全适合直接暴露给客户端，因此格式化最终消息客户端应执行糟糕...出了点问题。在其他情况下，我可以看到API部署，因为P.O.需要将 Oops更改为 Uups，类似的事情似乎完全与客户端应用程序IMHO的外观有关。

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.

推荐答案

您是对的，大多数时候您不需要向客户端公开REST异常，因为REST错误过于技术性。

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)

这篇关于REST API错误消息是否应国际化？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！