Suponha que uma API restante retorne esse json:
{
"status" : "fail",
"data" : { "title" : "A title is required" }
}
Como o aplicativo cliente sempre adaptaria a mensagem de erro, seria melhor retornar uma chave i18n explícita que o cliente teria mapeado em vez de "Um título é necessário"? :
{
"status" : "fail",
"data" : { "title" : "error.creation.title.required" }
}
Na verdade, o ponto é esperar que o consumidor da solicitação (aplicativo da web, por exemplo) traduza facilmente a mensagem em relação à sua localização.
Se você estava definindo um formato de erro comum para sua API, consulte também "Detalhes do problema para APIs HTTP ". Você não precisa dizer "status: fail" porque ele já deve estar indicado no código de status. Você pode usar o URI "problemType" como chave.
Para clientes que não querem traduzir a mensagem de erro, eles devem usar o cabeçalho Accept-Language para que o servidor saiba qual idioma precisa falar.
Um caminho a ser seguido seria incluir um sinalizador em sua solicitação se o usuário quiser ter uma chave i18n.
host/page?somrequest=somevalue&flagi18n=true
Vendo este sinalizador, você pode deixar sua API retornar a chave i18n. Caso contrário, você retornará a mensagem no idioma padrão.
Dessa forma, você mantém sua API desacoplada do cliente. Para mim, isso é uma questão de preferência.