REST caught my eyes back a few years ago when I first saw the book title in a local book store. I browsed through the book introduction, it intrigued me so much, that I decided to visit back later to get a full hold. Now in reading about the AJAX web revolution, I ran into REST again. What an amazing quiet revolution REST has brought us!
After some reading and thinking, it’s clear that REST is about rediscovering the powerfulness of internet technology, by going back to its very origin. That is you use only GET/POST/PUT/DELETE remote methods. In contrast, the whatever webservices (or COM/DCOM/CORBA etc) invent complicated rules to give you the power to devise any remote procedure calls. As Fielding, the inventor of REST, pointed out, those are misuse of web interface. It’s such a simple fact, but you’ll only see it and know it is so genius if you’ve suffered from complicated porting of local procedure calls to distributed systems. You could truly believe distributing the local procedure calls to remotely connected modules will magically make a working-system become distributed. Only that Fielding is saying no, no, don’t do it. As the other authors say it in different words, the heavy weight web services are hard to design, hard to understand, hard to implement, and impossible to test and verify.
In a debate between Linus and Mr Tanenbaum about micro-kernel, Linux specifically expressed the burden introduced by the “distributed algorithm”. The link is here: micro vs monolithic kernel. The heavy weight webservices are basically big piece of distributed algorithms tied by hundreds of so called API interfaces. While the REST, simplifies them into only 4 calls, and the REST goes on to say those 4 calls will return you with the state, state represented by web pages!
The REST is about state! State based design is another proven design method in that it tells the designer/implementer exactly what the system current state is. Without the state, if you want to verify a system you would have to go through endless call sequences to exhaust the event paths. That’s what featured oriented testing do. With state, you can just put the system into a state, then exam only the few outgoing paths. That’s white box testing. Or in another words, it’s about controlability and observability in systems engineering’s terms. That’s the essential requirements if you want to design and test a stable system in systems engineering’s domain.
It’s easier to understand if I say that in REST you get a really narrow API. We always know the simpler the API, the easier to implement the system. That’s how to view it in a software engineer’s scope.
I can feel the RESTful approach is truly meaningful ways of designing systems, if you care about the stability and completeness of your system.
Finally, have some amusement by this interesting article about REST. Have fun reading!