Ebenezer Ikonne

It's that time of the year, when I have to look at architecture styles.  The last two years have really been focused on getting apps to the .NET framework and dealing with some other stuff so I am really catching up on stuff.

So I discovered REST over the weekend and found that Savas talked about it while talking about MEST.  I also checked it out at Wikipedia to get more information.  Finally I did an (in my opinion) exhaustive search for more information.

I was disappointed that there really weren't “examples” of how to come up with a REST-based solution in the .NET world.  I saw a couple of Java based examples but for all the information that existed stating how many solutions (Flickr, Yahoo etc) were REST-based solutions, there is little practical technical guidance of how such systems could be built other than conceptuals.  Being a .NET guy (primarily), I had wondered if there are any .NET-based implementations but I imagine that I would have to create a couple of custom handlers to handle HTTP requests.

Then again, I wonder if this is primarily a Java-based solution due to some of the limitations with CORBA and RMI.

Another thing that I don't get is how an “architectural style/guide“ can be tied to be technologies.  To me it seems its no longer just a “style“ at that point.

Now on to MEST.  This is still in it's conceptual phases, but I've spoken to Udi about some of this stuff and it also does seem interesting.

I was actually going to prototype something (for kicks), but then it occured to me that to a large degree, these so-called styles are very similar - to me it's all about abstraction at the end of the day.

I've read (and seen) posts similar to What's wrong with Request/Response that somewhat “attack“ RPC.  I believe that we all forget that at the heart of RPC (and technologies built on this model) lies a messaging infrastructure.  Granted the abstraction of this messaging infrastructure led to bindings and dependencies that we are trying to get out of today, but that doesn't make RPC evil, it's the technologies and “programming style“ that resulted from RPC that have become evil.

Now we have elements that are considered ubiquitous, the two most popular being XML and HTTP and this all of a sudden allows for a programming model that allows two parties involved in communication to (a) agree on how they will communicate and (b) what they will communicate i.e. the “message“.  In my opinion, the REST advocates stop right here and say “we will always communicate by GET, POST, PUT and DELETE” once you tell us your URI and what “resources” you expose.  Behind the scenes, exist handlers that parse the XML message sent based on the “request type” and perform the necessary operation.

Web Services (document-style), format this “message” a little more by including (and inflating) SOAP tags.  Note that Web Services (at least in the MS world) can be setup to handle GET requests (let's be honest PUT and DELETE and not commonly used).  The “web service” framework abstracts the “handler” logic that has to be built in non-Web Service REST solutions and goes on to perform the necessary operation.  If you really think about it, Web Services are easily RESTful.

I know I have somewhat over-simplified things, especially if you Web Services in a RPC-style fashion.  But then again, what's wrong with doing that?  I would actually contend that the bigger issue is not treating everything as “noun”, but rather making sure your “messages” don't change overnight because the two parties involved in communication have agreed on a message format.

REST suggest that URIs should not contain verbs; the message should contain the verb that will be operating on the noun and actually site this as a weakness of RPC-style web services, failing to remember that the verb in also enclosed in the message. They also forget that HTTP is inherently RPC i.e. request response.  The major difference is “how” the client access the “service”.  With a “proxy”-based approach, there is more of a dependency created.  More similar than different in my opinion.

MEST (based on what I've read) makes signficant advances as an architecture style because it suggests no dependencies on any transports.  This is extremely important, because not all distributed applications are “distributed“ over the WAN and hence don't require HTTP.  Due to its one-way nature, it also support asynchronous behavior out of the box.  However, the “asynchronous“ debate has also become quite ridiculous and I hope to address it soon.  The same “message” design challenges that exist with communication between two parties still exist.

While I won't go on a diatribe like REST and Religion I won't hesistate to say that developer productivity has to be carefully weighed in all this discussions and that the three most important things are:

1. understanding requirement - there is no silver bullet for all problems
2. understanding architecture styles - realizing the ways to build solutions
3. understanding technology - using technology in architecture styles to address requirements.

I find that the visionaries talk at level that the mere mortal developer can't comprehend.  We need to remember that the tools available abstract so much that a lot of the fundamentals don't always “make sense”.  This is something that needs to be addressed.