the idea of defining a Formal Hypermedia Context definitely has some appeal, taking the rather basic HATEOAS principle one step further. thinking about Media Types and Resource Types basically moves in the exact same direction: figuring out what it takes to describe and then use a RESTful service. deciding on a transition in a RESTful service not only depends on the links found in representations; it also critically depends on understanding (a) where to find those links in the first place (link syntax), (b) what those links mean in the context of the RESTful service (link semantics), and (c) which link to actually follow to achieve the application goals (link pragmatics).
we are currently working on a description language for RESTful services which is trying to make as much explicit about a RESTful service as possible. it is a bit similar to the model recently presented on InfoQ, but extends it in a crucial way. the InfoQ model has link relation types and XML schemas, but since there is no existing XML schema language that explicitly supports a link type, there is no way how a link can be found in any given XML. we change this by adding selectors that allow to select links in XML using XPath. XPaths may select URIs, but they can also just select IDs which can then be transformed into URIs by applying link-specific rules, such as adding a prefix.
this idea of computing links
based on the hypermedia context
could be as simple as prefix/postfix, more sophisticated such as using URI templates, even more sophisticated in the case of a even more expressive language for computing URIs. taken to the extreme, such a of link computation
could even include variables carried over from previous navigational actions, in which case we would lose some of the nice context-free properties of one-step-at-a-time hypermedia links. we are still experimenting with how expressive these languages should be (so that more real-world services can be described, even if their RESTfulness is less than perfect), and how constrained they should be so that they're reasonably easy to understand and use. for now, we might just go the simple prefix/postfix route, but exploring the idea of a more formal model certainly would be an interesting exercise, and also help to understand at which point a more expressive model starts to compromise some core principles of REST. my guess would be that local link computations
are acceptable, but that starting to carry over state from previous link traversals would too clearly collide with the HATEOAS principle.
Comments