11/19/07 :: [SOA] Bill de Hora complains about the RESTlessNess of RESTFaces [permalink]

In my last post on REST I was saying that the real question was :

... the real question is how do you model an action to transition a resource from one state to another?

The REST community did not really pick on that one. I am not surprised. Let me explain why I am not surprised: the irony is that Representational State Transfer cannot efficiently deal with the state changes (content and lifecycle) of a resource. Let me prove my point.

Let's take a Job Application resource. Its lifecycle should look like something like this:

this is the state machine of a job application

Now, Bill de Hora complains that RESTFaces has nothing really RESTful about it and marvels at RESTLets. This framework implements the concept of a router that associates URL syntaxes with class definitions:

// Create a router
Router router = new Router(getContext());

// Attach the resources to the router
router.attach("/users/{user}", UserResource.class);
router.attach("/users/{user}/orders", OrdersResource.class);
router.attach("/users/{user}/orders/{order}",
        OrderResource.class);

// Return the root router
return router;

In this framework, not surprisingly, a resource class has two methods:

  • Representation getRepresentation(Variant mimeType)
  • put(Representation r)

The fundamental question is not so much about GET, but PUT. Ironically, the web architecture document labels put as an unsafe interaction (I am pretty sure this word was chosen on purpose, see below :-). While requesting a PUT how does the client knows:

a) the types and constraints that will create a well formed resource representation that can be "put-back".

b) (now, the interesting question) the correct states and transitions.

What's the most efficient way to communicate these two pieces of information between a client developer and a resource developer?  Let me think a nanosecond before I give the answer: a schema and a business interface. In REST you have neither, absolutely, positively, idempotently neither. Yeah, you get a nice PDF or Text file describing what you need to do. If there are "multiple versions" of the content and lifecycle, well you just hope you got the URL right.

In reality, the lifecycle mandates a business interface (either implied or explicit). A business interface that needs to be both known by the "client" and the "resource". The operations of a Job Application "service" are associated to each and every one of the transitions within the lifecycle.

the job application service operations are constructed from the transitions within the state machine

Mark, I don't think you can express the business interface in a RESTful way. REST says PUT is enough (I need an out-of-band contract to express it). The reality is that sure, Google, Yahoo, Amazon are ready to sacrifice the business interface to gain in scalability. There is nothing wrong with that, they have few interfaces and can easily ask their "clients" to figure it out. Their interfaces are fairly static. In the enterprise you generally don't care too much about scalability, you care a lot more about your content updates and state transitions. This is why you have information systems in the first place. You can't sacrifice anything in content update and state transitions. Since this is really important to you (you will generate a fault if something is wrong) you want to push as much knowledge to the consumer such that faults are the exception, not the norm.

The class of problems addressed by REST is far, far away from the day to day needs of an enterprise. If you have requirements that are well addressed by REST, this should be your first choice by far. However, if you need to build your next solution and need to deal with change efficiently, well REST is not the answer, by far, by very very far. So I am not surprised RESTFaces is not so RESTful afterall.

|