REST attempts to answers the questions of: What properties of the web have made it so successful? How can I apply these properties to my applications? While REST is simple, it takes awhile to figure out how to follow this architectural style effectively when designing distributed interfaces. REST promises greater decoupling, change resistance, and scalability if its principles are followed. The thing is though, for anybody not fresh out of school, we’ve heard these types of promises again and again over the years made by various industry efforts: DCE, CORBA, WS-*, and insert-your-favorite-distributed-framework. While the success of the Web leads me to believe that REST principles are strong, there has to be something more fundamental that it promotes or we’re never going to break the cycle of complex, bloated, infrastructure runtimes. That’s why I’ve adopted a set of core values for myself when writing RESTful interfaces.
Perhaps the most important reason why developers initially are attracted to REST is that, at its core, REST is very simple HTTP interactions. A good restful service can be understood simply by looking at the messages that are exchanged. If you were around in the early days of the web, did you look at HTML source to learn how a specific website wrote their page? Same applies to RESTful web services.
To write a RESTful web service all you need is a platform that can web requests. You can write restful services using Apache+CGI+(python/php), Servlets, JAX-RS, Restlet, Rails, Grails, whatever. From a client perspective, all you need is an HTTP client library. While frameworks can make you more productive, just using an HTTP client library is practically productive enough.
Lightweight, true, interoperability
Have you ever had trouble getting two different CORBA or SOAP vendors to interoperate? What about getting two different versions of the same vendor’s CORBA or WS-* stack to interoperate? These are common problems that happen every day with traditional stacks. Because REST focuses on exchanging representations through ubiquitous protocols like HTTP, these interoperability problems, on the protocol level, pretty much don’t exist. HTTP is everywhere and well supported. HTTP content negotiation allows clients and servers to decide, at runtime, what formats they want to exchange. REST+HTTP removes the vendor interoperability problem and allows developers to focus on application integration.
Frameworks for productivity, not for coupling
REST frameworks should help with developer productivity and not create a lockin between the client and server that requires the framework’s runtime be installed on both sides of the pipe. I feel this will lead to interoperability problems and complexity.
I’ve been yelled at before for stating my core values on why REST is important to me. I think I was misunderstood. I think there’s a distinction between what you want to accomplish and how you accomplish it. Right now REST is the how, and my core values are the what. Also, these core values are why I’ve been skeptical openly about things like WADL, Atom, RDF, and PATCH and why I’m nervous about how transactions are going to turn out in our REST-* effort. After all these years, its so important to get things right.