Retrofitting RETRO

ICWE 2009 was an interesting conference, and one of the good parts of it was the fact that even though it still has a substantial model-driven engineering bias, there are signs that other communities start recognizing the conference as well. i hope this trend will continue, and it definitely will be interesting to compare the programs of the 2009 and the 2010 conferences (btw, ICWE 2010 will be held in vienna, hosted by TU Vienna).

one of the people at ICWE was alexandros marinos, one of the creators of RETRO. RETRO recently caused some discussions in the REST communities because it tries to provide a RESTful approach to transactions, which often are more perceived as being in the realm of RPC/middleware oriented approaches to web services. i guess, if you want to use REST and transactions, there are three basic approaches:

• leave the transaction semantics in the application, so that clients just need to know what is going on. this is not loosely coupled, and makes it impossible to provide tools and support for transactions.
• introduce new methods. this is what WebDAV did by extending HTTP with new methods. this is a very clean approach, but also one which makes adoption rather hard.
• introduce some overlay of links and/or resources that represent the transactions. the magic .../lock resource is one such thing, but as long as there is no way how it can be discovered, this also falls into the first category. otherwise, there have to be ways of how links and/or resources can expose their transaction semantics.

the RETRO approach falls squarely into the last category, and personally, that is the category that i prefer. there are three issues i have with the (admittedly very early) draft:

• it seems to me that not all of the resources introduced in the model are strictly necessary, and least not as publicly available resources. it would be interesting to look at the minimal core, and define all other resources as optional.
• RETRO introduces media types and suggests to include a certain XML fragment in lockable resources. it would probably be more consistent and more extensible to just require certain vocabularies be present in the resource representations, so that each service could (if it wanted) use its own schema, importing the RETRO schema. RETRO could still provide default schema to use for those services that do not want to define their own schemas, but link discovery should be based on namespaces and imported schemas, not on media types.
• changing URIs from transaction-contained resources to the eventual URI is a pretty major operation. at least, there should (or maybe even MUST) be an xml:base in the resource that always sets its base URI to the final URI. and generally, i am asking myself whether this identity switch is not a potential source of confusion and/or errors. would there be other ways of doing this? and is it even necessary to have these temporary resources, or are they also optional and not part of the core model?

but even though i think the model could be improved, i really like the direction, and i am particularly interested to investigate potential synergies with LDX, which currently mainly is an idea and a first sketch, but will get more attention soon. i still think that REST's idea of placing hyperlinks in the core of the interaction model demands something like LDX: a way of how to make statements about links and their semantics (in the sense of link roles). combining RETRO sans media types and using LDX as the way to specify RETRO's interconnected transaction resources could be a nicely flexible way of allowing services to use their own media types (as long as they're XML), without sacrificing the discoverability of the RESTful transaction links.