ABOUT | COPYRIGHT

Service Oriented, Process Centric, Model Driven Heresies

	del.icio.us
	Digg
	DZone
	Furl
	Reddit

Subscribe in a reader

01/26/09 :: [REST] RESTful Patterns [permalink]

Lots of activity on REST last week. Bill Burke released RESTeasy and J.D. Meyer's team came out with a set of implementation patterns that facilitate RESTful service implementations.

The good thing about all this RESTful activity is that we finally have some very concrete stuff to talk about, no more hand waving by the RESTafarians who like to think of their opinion on whatever stuff as solid reasoning.

Let's start with RESTeasy. As you may be able to tell, I was very interested to see how JAX-RS and Bill used "POST" in their model and how HATEOAS would surface. Well HATEOAS is "out-of-scope" for that and POST is used classically to add resources "around" an existing resource (e.g. POST a reservation to a tennis court resource to perform the "reserve" action).

JAX-RS is very sparse on the usage of @POST. This is the only time it is mentioned in the 49 pages spec:

@Produces("application/widgets+xml")
public class WidgetsResource
{
@GET
public Widgets getAsXML() {...}

@GET
@Produces("text/html")
public String getAsHtml() {...}

@POST
@Consumes("application/widgets+xml")
public void addWidget(Widget widget) {...}
}

Now, adding resources right and left is what REST wants you to do. as I mentioned, this is quite an odd model because the question is how do you figure out whether a tennis court is reserved for a given time? Do you "try" to POST a reservation and wait for an error?, if not you immediately cancel it. Do you ask for all the reservations resources and figure out for yourself? Do you ask the "tennis court" if it is reserved? If so, how? remember, your "request" must return a resource representation of some sort? In reality, the wonderful world of REST is going to turn into a massive CRUDing orgy who has the potential to kill the concept of "connected systems". RESTafarians, shortsighted as they can possibly be, don't see the coupling that is introduced by CRUDing, even if, you, like Microsoft, use the incredibly innovative concept of "Application Lifetime States".

J.D. Meyer's view on REST implementation is no different. Here is the key to Microsoft's vision to implement REST: the Entity Translator pattern:

Implement an object that transforms message data types to business types for requests and reverses the transformation for responses.

... [he explains:]

Resources exposed by the service represent an external contract while business entities are internal to the service. As a result, translators are required to move data from one format to another.

J.D. shows either how ignorant he is about REST or how blind the RESTafarians are about actions (which ever you prefer) since he recommends using the Façade pattern just behind the translator pattern:

Implement a unified interface to a set of operations to reduce coupling between systems.

... [he explains]

Rather than defining chatty object based operations a façade combines multiple operations into a single interface.

So just how, POSTy is Microsoft's view of REST? Check this wonderful "Promote" action !! Of course, J.D. is going to explain you that the purpose of the wonderful machinery he has put on top of the promote action is precisely to enable consumers to POST a "promotion resource".

But then the question is what for? what have we gained since we are calling the same old code? absolutely nothing. However, in the process we have lost the key advances of this decade in terms of middleware:

bidirectional interfaces
forward compatible versioning
assemblies (such as SCA)
orchestration languages (such as BPEL)

This is incredibly sad, the middleware intelligentsia has lost its way. They simply don't understand that to make any progress, the application model and the middleware has to complement each other, in other words, the application model needs to be message oriented. Adding annotations to corny OO concepts (which are used to generate boiler plate code) is what is wrong and what has been wrong ever since CORBA, whether you Object Orient, Service Orient, Resource Orient or Event Orient these annotations. How could all these people believe that this is an "annotation" problem?

Never more so, my 2002 post on "The End in Mind" has been so current. Yes, Stu, our industry only knows to circle back... no matter what you feed it.

Yes, you guessed it, if all that the RESTafarians achieves is to "route" calls to the Same Old Code, we would have lost everything: Service Orientation, Resource Orientation and Event Orientation, all together, in one big swoop. Thank you guys ! What an achievement ! I do not mean it has to be that way at all. I respect Resource Orientation as a concept as long it is well articulated with Service Orientation and Event Orientation, but this is not what the "Wild Bunch" has in mind. They can't care less about articulations. They want a bloody dominance (a.k.a reification), and we all know how this will end up: dominance will only lead to its demise.