Implosion of REST Frameworks?

Applying REST principles to a complex Enterprise is harder than applying them to a photo-database or a blog-site (aka skinned database). No points for that one. Why do it? Well treating an Enterprise as a set of ‘resources’ with representations and behavioural contracts applied to attributes manipulated through a uniform, ubiquitous interface is a liberating experience on the design-slab. However when we come to take real steps we are beset by 2 key obstacles:

1. Resource representations are abstractions of a complex information architecture underpinned by many diverse and evolving IT assets, so we do not have atomic control over the assembly of resource representations nor do we have atomic control over key-mastering and complex updates.
2. The resource Namespace needs to support hierarchy to ensure we can correctly structure context around certain resource-types who’s representations may be context-aware. As such depending on who is looking at what, there is a complex resolution of the public namespace to a potentially complex EAI landscape within the black-box.

Are these problems insurmountable? Well I don’t believe so, but the resulting shape of the framework I’d use to achieve this is significantly different to the emerging frameworks (i.e. JAX-RS/JSR311, Restlet, etc) geared towards resource-enabling stuff. Why?

The primary reason why I seem to be diverging from the direction being taken by the framework guys, is simply that (…note to self…I’m not officially recognising options which would require me to acknowledge that I’m being stoopid ) I need more dynamic processing in the mapping of a requested URI to a POJO/Controller. What does this mean?

Well – based on the 2 points I outlined at the start of this article the inspection, validation and refinement of my inbound URI’s are managed within a single control step, fed with meta-data and context info. Similarly, as I resolve a canonical resource (i.e. one which may be reached through a range of public namespace paths) I need to work out how best to ‘go and execute’ the require data-acquisition or functional RPC steps to implement the resource operation. Again – another control step fed with meta-data and context info.

What I end up with, is a processing chain from HTTP request through to Enterprise resource, where the namespace, URI resolution and method variations are simply parameters driving a more complex, dynamic integration broker. As I DRY up my code, I begin to refactor away from having explicit resource controllers be that at a class-oriented or annotation-based level.

Ultimately my ideal ‘REST’ framework is one which enables me to data-drive not only the production of a resource facade, but the linkages between those resources and complex integration/aggregation transactions, therefore imploding the more explicit genre of ‘REST framework’ in favour of a declarative alterative.

At this time I’m prototyping with SpringMVC Servlet/Interceptors and also raw Servlet/Filter chains, both of which are configured to have only 1 front-controller, and a series of processing steps as the inbound request is boiled down to a back-end transaction. The bulk of the manifestation of REST-oriented logic is meta-data consulted by the processing chain within the context of a user-initiated operation.

This is what I mean by Implosion of REST frameworks…

Ruby/Rails URI Patterns and JSR311

I had been working with a rails project mapping a uniform REST interace onto complex resource representations assembled at runtime, and as such no object/relational mapping was used to pull information from a local datasource.  Instead I use ‘virtual’ resource representations which are fulfilled on-demand, within synch or asynch interactions, from back-end complex back-end data sources and interfaces.

As such the primary Rails convention of mapping resource URI’s to controllers and actions, and through an object/relational layer to a datasource is effectively useless in my scenario. Instead of mapping resource to a datasource, I instead have to  map URI’s to a generic controller, still supporting the GET, POST, PUT, DELETE semantics, but essentially data-driving a dynamic integration tier with the resource context.

So if I were resource-enabling a database with  2 tables, customers and orders, then I’d use the following routes.rb entries (along with a rails resource scaffold) to build my URI to datasource relationships.

map.resources :customers
map.resources rders

This would route requests for http://domain:port/customers to the Customers controller, and route the http://domain:port/orders to the Orders controller, where each would sit across O/R mappings to specific tables in my database. Nice and easy !

However in my world the Customers resource and the Orders resource are virtual within the front-end runtime, and must be instantiated by using a dynamic mapping algorithm to initiate back-end integration transactions over a range of mechanisms to instantiate the correct representations for each resource type (focusing on GETS’s for this sake of this example). As such it makes  sense for me to have a single VirtualResource Controller, which uses request context information to infer the correct representation algorithm. Rails has a neat way of enabling this in the routing table:

map.resources perations, :controller=>"virtualresources"
map.resources :customers, :controller=>"virtualresources"

This enables me to pipe a range of URI patterns into my virtual handler and manage a lot of complexity through very few generalised routines.

At this point I’m considering the migration across to Jersey on Glassfish – using the JSR311 annotation scheme for this kind of URI pattern matching.

 @UriTemplate("widgets/{id}")
 public class Widget {
 ...
 }


Only problem is – at the moment I see no way of assigning multiple URI patterns to a single Virtual Resource class in the way I have with Rails. Only one URI pattern is enabled for each POJO class – which would mean I’d have to create many proxy classes into my virtual resource handler? I’m gonna have to dig a little deeper here but hope this kind of flexibility and learning from the Rails community will be factored into the JSR spec?

Rails, JSR311, Restlet and Jersey

In an earlier post (http://thestewscope.wordpress.com/2007/12/21/rest-moving-to-java/) I had declared my intention to depart from using Ruby/Rails as a means of creating RESTful web-services fronting what I regard as a more complex set of resource implementations than Rails appears to be comfortable with.

Since that time I’ve been investigating JSR3-11 and 2 early implementations on the Java platform, Restlet and Jersey respectively. The creator of Restlet (Jerome Louvel) is a member of the JSR3-11 expert group working on the evolution of the spec and as such is well placed to oversee the development of his very tidy Restlet framework. Jersey on the other hand is the Sun reference implementation of the spec, and relies more on convention and pojo annotation in place of the more structured/prescriptive framework put together in Restlet framework.

My initial feelings were that moving up the food-chaing from Rails (I stress that when I say food-chain I am implying an order of relative capability within my specific problem-space and not disrespecting the Rails community at all) that Restlet would be the more natural home or stepping stone towards an Enterprise class framework – which is effectively where I am exploring the applicability of RESTian principles….as an alternative to Enterprise SOA WS*. However as I have begun to dig deeper into the real requirements of ‘my next framework’ I am beginning to favour Jersey as my next hop. But I’m currently unsure of the relative merits…

Why?

Well Restlet offers a neat and slick way for me to assemble components with certain roles into chains, behind URI patterns enabling a lightweight RESTful facade to be created quickly but with a little more enterprise-integration power under-the-hood than rails. However the current evolution of Restlet appears to be a little limited in the area of connector classes and the tools that help me do the real work of applying my RESTful uniform interface to my complex enterprise engine-room. As a result – I believe I’d be dropping back to engineering the guts of my integration code on an alternative platform such as Glassfish. For that reason – I’m starting to think the Jersey option may initially offer the same ability to create a resource facade but also be a natural point of extension when I need to bolt heavier back-end integrations into the RESTful presentation. As such I can’t help but feel that starting out with Jersey on Glassfish would be a foundation that I could grow, as opposed to taking a step forward with Restlet but then relying on Glassfish hosted components down the line…

 One thing is for certain in my mind right now. RESTful principles applied to the Enterprise need more than Rails – but I’m still unsure of the Restlet/Jersey route…but Jersey on Glassfish just feel like they may just withstand a little more heat in an Enteprise scenario…