In my opinion, transactions in REST should be a pattern, not an implementation
Very interesting. While we named RETRO a 'model', that may have just been us unthinkinly echoing the previous transaction 'models'. The thoughts that follow apply both to RETRO and potential other RESTful transaction models (compensation-based for example).
During development, I realised that RETRO as it currently stands cannot be implemented into a generic, plug-and-play solution that you would add to your custom RESTful API to magically give it transactional capabilities. The reactions of the server depend on the resources that can be locked, their interlinking, and the related side-effects. In the general case, RETRO can only be implemented in relation to a pre-existing API. So no reference implementation for RETRO, then. Perhaps the closest thing we could produce is RETRO over ATOM, or something along those lines, again with the server taking responsibility for managing any other side-effects.
Also, since RETRO is HATEOAS-based, standardising the entire protocol would be a contradiction in terms, as that would be the very definition of out-of-band information. Nevertheless, HATEOAS leaves a pretty big door open, and that is media types. In the model we have mentioned that Transactions and Locks would need their own media types. If there was a way to semantically self-describe a media type (yes, I enjoy causing trouble it seems) we wouldn't need to standardise that either. The way things are now, for RETRO or any other transaction model would need at least some media types to be considered 'known' before being applicable.
So, Model, Standard, Implementation, or Pattern? Well, I think pattern with a little bit of standardisation for the media types should do the trick.
No comments:
Post a Comment