Written by: William Martinez Pomares
Published on April 9th, 2009 @ 11:06:45 pm , using 559 words
Published on April 9th, 2009 @ 11:06:45 pm , using 559 words
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
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.
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.
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.
