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
- Invent a new request header
- Supply additional metadata in a multipart/related document
- Provide language as a parameter to the
Content-Type
of the request, likeContent-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, becausePUT
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 thinkPOST
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 (usingPOST
/PUT
/DELETE
resp.), while during aGET
request of/publication/XYZ
you could examine theAccept-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.