Why do we talk about The Why of REST?.
I recall the old days, when I first met REST. It was introduced to me as a revolutionary way to create web services without all the complexity of SOAP and WSDL. It was an airline system used as an example. Very simple to understand. And yet very suspicious.
I had lots of questions in the following hours. The explanation was somehow light, and it seemed to me like a normal web request, nothing similar to a service. Later I read the REST dissertation (I actually did some annotations that I was to put in a blog post, and never did), and found out REST was an architectural matter, far more than just a web request.
I kept on the searching and found several examples claiming to be REST incarnations, but they were clearly not. I found several implementations were REST didn’t even fit.
How so? May you ask. Isn’t REST a solution for everything? Isn’t REST an API, or an API creation technique? Isn’t REST a Services creation technology? Well, no.
REST was not created to be used on SOA as a service creation technique. The origin of REST is quite different, and it is tuned for specific problems found when creating systems like the web.
Actually, REST is an architectural style, and it is made out of a set of different sub-styles, each of them is there for a reason. Each style is a set of constrains, that has some benefits and some drawbacks, all carefully balanced to fulfill the need of a particular type of application.
Many tutorial show REST as something for the developer, when implementing a service on the web, full of tricks and tips on how to replicate the normal language and system operations over the HTTP protocol. Instead, REST should be seen at architectural level, where trade-offs are generated due to constrains, and for that we need to understand why each of those constrains are in REST to begin with.
This presentation will try to work on REST from the architectural point of view (Yes, no GET-POST-URI examples). Why is it a Networked System application so different, and why the REST constrains may help (after checking, of course, what those constrains are and how they impact the architecture). At the end, we will have some minutes to discuss in which SOA flavors does REST fit, and why is it not good for everyone. Several “whys” to explain, the big Why of REST.
