REST architectural constraints and REST pattern language
REST is presented as set of architectural constraints. Most of the 'popular' REST literature (at least at the entry level), concentrates on definition of resources and resource identifiers.
But I think resources and resource identifiers should always be thought of in the 'context of' other constraints.
I was recently having a discussion with some colleagues about RESTful URIs for website we are working on. We need to display universal products and regionalized products
The URLs are something like
When I said that, we should have separate unique urls for regional products like
Some people said that regions don't need be part of URL and we can get those from user preferences in HTTP session, keeping urls same.
Everyone was forgetting 'stateless' constraint and almost assuming the existence of HTTP Session object provided by application servers.
Thats when I thought, if REST is presented as pattern language, with explicit relation between patterns and stating which patterns are context building for other, will it be more useful to teach and design websites?