I'm designing RESTful API for my application. I have entity that is multilingual. I wonder if I should think about this entity as a resource that has multiple representations - one per supported language or I should do multiple resources and introduce language part in URI.
In my case, the lifecycle of entity is as follows:
- user adds entity in EN language version,
- after some time (could be several months or never) user adds other language version.
Is in the valid RESTful design all representations should be available immediatly after POSTing resource to server? Or maybe REST allows adding new representation as a result of business process not architectural change (implementing possibility to get XML representation along JSON is not the case)?
You can either use the HTTP header "Accept-Language" to indicate what language to fetch - or include the language in the URL - or both.
Using the header seems like the most elegant way as your resource will have a stable URL for all languages. This means your resource will be identified by one and only one URL.
On the other hand it can be useful to share a URL to one specific language version of the resource - by including the language in the URL. This means your resource will be identified by many different URLs - conceptually splitting it into multiple resources.
Both ways are valid solution that doesn't break any REST constraints.
REST does certainly allow you to add new representations of the same resource over time as business evolves. One single resource (identified by one single URL) can have many representations depending on various HTTP headers - "Accept-Language" is one, just like "Accept" that indicates what format the client prefers (JSON/XML/HTML/other).