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.

  • Can you localize on the server side based on the client culture?
    – Matt H
    Commented Nov 29, 2013 at 0:31
  • @Matt H No, I want it to be totally decoupled from the nature of the client preference.
    – Mik378
    Commented Nov 29, 2013 at 0:36

2 Answers 2

  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.

  • At the bottom, it's advised to precise status even if it's already available from status code: labs.omniti.com/labs/jsend
    – Mik378
    Commented Nov 29, 2013 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
    Commented Nov 29, 2013 at 1:48
  • Understood, interesting :)
    – Mik378
    Commented Nov 29, 2013 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.


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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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