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…

Advertisements

2 Responses to Implosion of REST Frameworks?

  1. Paul Sandoz says:

    Hi Stew,

    If you have the time I would be interesting in understand more about your use-case to know why JSR-311 sub-locators are not sufficient. Do you require richer path matching semantics than that offered by @Path and URI template?

    The sub-locator concept is a dynamic point of hierarchical control of the resource Namespace. A super-resource can determine based matching portions of the left-hand-side of the URI path and other application-defined contextual information what sub-resource object to return that processes the right-hand-side of the URI path, and so on recursively until the URI path is consumed and an HTTP request can be dispatched to a HTTP method that returns a representation.

    So the sub-locator this mechanism is like an application-defined switch. In this sense a resource in the JSR-311 sense may not be responsible for serving an HTTP request but may be solely responsible for returning other resources that do, directly or indirectly. It is really about application-based routing and mapping bits of the URI path namespace to Java classes that know what to do with those bits of the URI given a certain context.

    BTW with Jersey it is now much easier to wire Spring support with resource classes and i have just committed a fix to the latest build to ensure that a sub-locator can return a class that participates with Spring.

    Paul.

  2. Stew Welbourne says:

    Hi Paul. So again this may be an edge-case based on my specific goals, so I’ll try and lay it out. In very basic terms, what I’m getting at is the fact I want to avoid using @Path annotations across lots of places where the method implementations are simple delegations to other controllers. As such all of my front-end entry-points can be DRY’ed up resultnig in a single controller (i.e. servlet taking method/URI/context), and making decisions upon how to route by consulting meta-data.

    So where we have a reduction in the ‘framework’ control plane, effectively now occupying the inbound routing, and where I DRY up my front-end methods based on their duplication (i.e. calling a resolveRoutingDecision(method, uri, stuff) kind of model, then the role of the framework effectively implodes to very little i.e. annotating a single front-end controller method with @Path(“/*”)….sort of what I can do with servlet or other more basic http handlers.

    I need to be clear that I’m not questioning the need for more explicit frameworks, nor the great work you guys are doing to promote this area, which enables rapid wiring of a published namespace to resource-oriented systems and methods returning representations, but in my world, the RESTful facade is just that, a facade which relies upon an algorithmic mapping, through a series of generalised-controllers, ultimately resolving to a back-end integration transaction, before the return trip can commence. Sort of along the lines of servlet filter-chaining if you will….where each step uses the context as a means of resovling to the next step.

    If I can get some time I’ll drop you more explicity examples onto the mailing list.

    Cheers
    Stew

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: