Best practice regarding REST services and I18N

I have a client app that communicates with a server using REST services. The client app is multilingual which means the server must be aware of the user's locale during calls. I want to use the "post for location" approach as that has a nice and restful feel to it. When data gets posted to say the actions resource then the uri is:

/actions/{language}

The language is important so that I can localize error messages (or sometimes the retu开发者_如何学Gorning data) for a GET. Now when the server responds it needs to send back the URI of the resource. If I send back

/actions/{id}

where id is the id of the newly created resource, this isn't entirely correct as

/actions/{language}/{id}

would be the URI of the localized resource. However the actual resource is without the language context.

Any opinions on best practice for this scenario?

Use the Accept-Language HTTP header.

I'm not convinced that the language should be part of the "address", the thing that identifies the resource, unless it truly is part of the identity, and the tension you have between

 /actions/{id}

and

 /actions/{lang}/{id}

shows that something is not right.

One alternative approach is to use the HTTP header locale information to pass the language. Another would be to pass the language as a query parameter, it is a modifier of the request.

Couldn't find how to comment but I will go with djna answer. Just wanted to add some:

I'm not a REST expert, but from my point of view, query will be the perfect solution AND supporting HTTP header locale as well.

Example, if HTTP header is sent, use that. If query param lang is sent, override HTTP header.

So you get:

/actions/{id}?lang=es-la

Also, you can specify a default language, not strict to one (but I think it's best to say, English if not specified), but you can get user GEO location to present the info in the clients language, if they don't specify one.

Also accepting the HTTP header goes one step further and giving the client options. It's much easier to configure a HTTP header than to manipulate every request URL with language in the client.

Hope it helps :D

In my opinion, you need NOT support Internationalization/Localization in your RESTful Server side.

For a app with a backend RESTful server, the internationalization should be done in Client Side (Your Android App, your web 2.0 Web Page, etc ).

But you should format your error response, for example:

{
    "code": "NET.001",
    "message": "The remote host can't reach"
}