Rest – How to indicate to a web server the language of a resource

httphttp-requestrest

I'm writing an HTTP API to a publishing server, and I want resources with representations in multiple languages. A user whose client GETs a resource which has Korean, Japanese and Trad. Chinese representations, and sends Accept-Language: en, ja;q=0.7 should get the Japanese.

One resource, identified by one URI, will therefore have a number of different language representations. This seems to me like a totally orthodox use of content negotiation and multiple resource representations.

But when each translator comes to provide these alternate language representations to the server, what's the correct way to instruct the server which language to store the representation under? I'm having the translators PUT the representation in its entirety to the same URI, but I can't find out how to do this elegantly. Content-Language is a response header, and none of the request headers seem to fit the bill.

It seems my options are

  1. Invent a new request header
  2. Supply additional metadata in a multipart/related document
  3. Provide language as a parameter to the Content-Type of the request, like Content-Type: text/html;language=en

I don't want to get into the business of extending HTTP, and I don't feel great about bundling extra metadata into the representation. Neither approach seems friendly to HTTP caches either. So option 3 seems like the best way that I can think of, but even then it's decidedly non-standard to put my own specific parameters on a very well established content type.

Is there any by-the-book way of achieving this?

Best Answer

First of all, let's give your resource a name: let's call it a publication. This is to disambiguate it from another kind of resource your design is implying: the translation.

Second, let's agree to the fact that a collection of resources is also a resource itself. Having said that, a publication looks to me more like a collection of translations.

Third, using PUT to create a translation seems inappropriate to me, because PUT is used to replace a resource with another one. It would make sense if a translation to a specific language was already there, and the translator was updating it. But to create a new one, I think POST suits best.

EDIT: I'm having second thoughts on the above. It appears that, since the id of the new resource is decided by the client, a PUT would actually be appropriate after all. Maybe someone else could provide a more concrete opinion on the matter.

Now, considering the above, a uri structure like /publication/XYZ/en would certainly make sense, because it would refer to the English translation of the publication with id XYZ. This resolves the creating/updating/deleting of translations (using POST/PUT/DELETE resp.), while during a GET request of /publication/XYZ you could examine the Accept-Language header and make the client redirect accordingly.

OTOH, your question clearly states that you want to treat the publication as a single resource. In that case, I guess you must treat translations as separate attributes (i.e. fields) of the same resource. Just as a person resource would have a first name, a last name and an e-mail, a publication could have a publication date, an English translation and a Japanese one.

But then you would have to find a way to partially update the publication when a translation would need to be created/edited. I guess a PATCH request would be appropriate for this scenario.

Related Topic