tags:

views:

32

answers:

1

I'd like to have my resources localized to several languages. How multiple languages should be posted to resource using REST architecture?

resource: /chapters, /chapters/:id

When POST is issued to chapters, client send data structure:

{localizations: { en: {title: 'New chapter' },sk: {title: 'Nova kapitola'} }}

and new chapter with localizations en and sk is created.

When client wants to access this chapter at URL /chapter/1, only one language mutation should be returned in representation. How should I implement locale scoping? I can use Accept-Language HTTP header with desired locale, Accept-Language: sk, or i can include locale into URL like /chapters/1/en.

Also, how PUT request should be handled? For most of the time only one language mutation would be updated, but occasionally 2 or more of them would be updated.

+1  A: 

For updating the data, the language should be provided in the payload of data, just as you've described. That works great.

For fetching, it depends on if you want to allow 1) linkability, and 2) clients to change their selected language. I'd argue you want both - its much easier and preferable to change the URL or toggle the language within your app then futz around in the browser and change the browser-wide locale settings.

So, check your url, application cookies, or application user data for the language, and use the Accept-Language headers as a fallback.

I don't understand your PUT request question. The data structure you describe would handle multiple language updates just fine, no? You can treat PUTs pretty much however you want, so long as the URL that is PUT to remains an addressable resource.

Richard Levasseur
Yes, linkability is imortant, good point.PUT, in this case update of existing resource, should be implemented as replacing current state with new state completly, this means sending all language mutations with one PUT request.Form most of the times only one language mutation will be fetched from server for processing.I think itll be better to expose each language as subortinate resource: /chapter/1/:language. This address linkability and also makes caching easier. Thanks.
Peter
Yes, that would work. You can also "overload" PUT /chapter/1 to look for the `localizations` structure you define in your question (to allow multiple updates in 1 request, which could be important in some situations).
Richard Levasseur