REST and the Wagging The Dog Syndrome.
April 9th, 2009
REST and the Wagging The Dog Syndrome.
Published on April 9th, 2009 @ 11:06:45 pm , using 559 words, 7179 views
Commenting on Tim Bray’s blog post about the use of Post for REST, I came to a discussion about actually how much RESTFull is an API, and more specifically if it should be RESTFull at all.
You see, many people is trying to get their APIs into the REST world, and some people like Dilip Krishnan believe the reason is to gain "simplicity, discoverability and serendipitous reuse of the solution". Still, as I read through all the comments on how to "imagine" the app so it fits REST, I feel a greater sense of something not right about it.
When creating a solution, you may want to analyze first the functional requirements, and then the quality properties. The ones noted by Dilip are great, but I’m not sure all apps that hit the web every day need to accomplish them. Furthermore, REST is not the only way of getting those attributes! Let’s explain a little what this famous style is so you can understand what I’m saying.
The REpresentational State Transfer style was born as an architectural style to represent/improve the modern web implementation, as Roy Fielding explains in his dissertation. So, REST is an architectural style, and that means it has a set of constrains that the app needs to adopt to obtain the benefits. But that architectural style is not built from scratch. It is built by composing several other well known styles like Client-Cache-Stateless-Server, Layered-Client-Server or Code-On-Demand. Any of those can be used separately and all their pros and cons will be cast upon the solution.
Now, this is a special case where an implementation is taken as a base to develop an architectural style that improves it. Usually, you have a solution to build with a set of requirements, and you look for an style that better fit into the problem. But once you start changing the problem just to adjust to an architectural style, you are actually “Wagging the Dog” there. And it seems to be a contagious syndrome.
So, what does it need to have an APP to be worthy enough to use the style? Well, first
- - the semantics should be the ones of the style.
- - Next, the app should try to solve a similar issue the style is solving, and third,
- - the app’s quality attributes should be the ones the style is promoting.
If some of the three is not true for your app, and you still want to use the style, I may guess you are trying to get the buzzword title instead of the real benefits.
One little clarification at this point: The web is one implementation that follows the style, it is NOT REST itself. What do I mean by that? Creating an app that runs on the web doesn’t make it RESTFull. Using HTTP for your API won’t make it either (I wanted to clarify it since all comments are about HTTP and its semantics and it seems everybody confuses the implementation with the style). You need to read the dissertation to learn all the constrains, but even more important, to learn if the style is for you or not. You may learn HTTP is not a required protocol, but one constructed that meets the constrains. You can build your own! (and make it standard).
William Martinez.
PermalinkTrackback address for this post
3 comments
The problem though is that the web is now ubiquitous and incidentally very successful, so there is a temptation to use (misuse?) it for everything.
Distributed computing is complex and difficult and the vendors have managed to mess it up even after having several attempts over several decades, so it's not surprising that everyone is trying to use the web for everything.
I really like this point:
- the semantics should be the ones of the style.
It took me a while to come to grips with the idea that you could express all your messaging needs within the REST constraints, and it still feels a little unnatural.
Having said this, I'd rather fit my application around REST then deal with many of the alternatives. I guess one way of looking at REST is as a pragmatic non-functional constraint.
The web exists already as an ubiquitous platform, and if you want to gain the interoperability that comes with building on a ubiquitous platform then REST is one sure way of doing it.
Paul.
Good point about the web. Still, and that is my understanding, you can use the web without being REST. REST is a style that brings benefits to the modern web (the distributed hypermedia application), and you can even use REST without being in web.
You can use the "ubiquitousy" of web without applying all restrictions of REST if you don't need all the benefits.
A style is something you can use as it is, or a base to create your own solution. What matters is the application, not really to fit into the style. If that doesn't allow you use the style's name, and that is important, then you have a trade of there: you lose in the app, but win on the name.
It is the app owner's decision.
Cheers
William.
So for compatibility and interoperability on the web REST is pretty hard to beat. The only problem I see is that to exploit the style means adopting an approach to messaging that is uncommon to most programmers.
In truth the scalability of REST and the RESTful infrastructure of the web (caches, routers, etc) goes way beyond the needs of most applications. So invariably REST will meet your applications needs.
Its a trade off. Adhering to a standard versus the freedom to create the optimal solution for your own needs.
It's like choosing Unix over writing your own custom OS. Most people will choose a standard, especially if it is a proven one.
Paul.
Comment feed for this post
