Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

Suppose a rest api returning this json:

{
    "status" : "fail",
    "data" : { "title" : "A title is required" }
}

Since the client application would always adapt the error message, would it be better to return an explicit i18n key that the client would have mapped rather than "A title is required"? :

{
    "status" : "fail",
    "data" : { "title" : "error.creation.title.required" }
}

Indeed, the point is to expect the request consumer (web application for instance) to easily translate the message regarding its localization.

share|improve this question
    
Can you localize on the server side based on the client culture? –  Matt H Nov 29 '13 at 0:31
    
@Matt H No, I want it to be totally decoupled from the nature of the client preference. –  Mik378 Nov 29 '13 at 0:36

2 Answers 2

up vote 5 down vote accepted
  1. If you were defining common error format for your Api, see also "Problem Details for HTTP APIs". You don't need to say "status: fail" because it should be indicated already in status code. You can use "problemType" URI as key.

  2. For clients that don't want to translate error message themselves, they should use Accept-Language header so server knows what language it needs to speak.

share|improve this answer
    
At the bottom, it's advised to precise status even if it's already available from status code: labs.omniti.com/labs/jsend –  Mik378 Nov 29 '13 at 1:35
    
@Mik378 Jsend is completely different. For one, it's json only. The Problem Details only tries to define error format, iow only for 4xx & 5xx responses. For other responses where you want to return resource entity you can use your own format or try (another draft standard) hal+json: tools.ietf.org/html/draft-kelly-json-hal-06. It's your choice. –  imel96 Nov 29 '13 at 1:48
    
Understood, interesting :) –  Mik378 Nov 29 '13 at 2:06

One way to go would be to include a flag in your request if the user wants to have an i18n key.

host/page?somrequest=somevalue&flagi18n=true

Seeing this flag, you may then let your API return the i18n key. Otherwise, you return the message in the default language.

This way, you keep your API decoupled from the client. For me, this is a matter of preference.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.