Right at the point when everyone considered the debate around REST to be over, there has been a new wave of REST publications. As Mark Little observed:
It's fair to say that the mere mention of the word REST causes polarization in people...
Following this trend, a new article by Ronald Schmelzer tells the story of why and how he moved from Web Services to REST.
According to Schmelzer and, consequently, ZapThink:
Representational State Transfer, commonly known as REST, is a style of distributed software architecture that offers an alternative to the commonly accepted XML-based Web Services as a means for system-to-system interaction... when I needed to implement the Services I had already determined were necessary, I faced a choice: use Web Services or REST-based styles as the means to interact with the Services. For the reasons I outline below, REST was a clear winner for my particular use case.
This statement by itself is an interesting one, because it directly contradicts one in a Dhananjay Nene’ earlier : post
Service orientation is neither essential for, nor is it the intention of REST. Not only is REST not service oriented, service orientation is irrelevant for REST... REST does not attempt to be service oriented. That’s because it does not view the process as a sequence of tasks to be performed. It views it as a sequence of resources under modification. To put it differently, it views the process as a set of actors who exchange resources (or documents for better visualization) and carry out activities based upon receipt of such resources.
So what Schmelzer is really talking about does not really seems to be REST, but rather what is often referred to as REST Web Service - an approach for using REST technologies to build SOA. Although commonly referred to as REST, this approach has nothing to do with true REST and is similar to POX (plain old XML over HTTP), with the difference being that in addition to XML, it supports multiple other data marshalling types ranging from JavaScript Object Notation (JSON) to ATOM to binary blobs and leverages additional HTTP methods, compared to POX, which is typically based on GET and PUT.
Schmelzer continues by saying that he:
... ended up using REST for a number of reasons, but the primary one is simplicity... REST is simpler to use and understand than Web Services. Development with REST is easier and quicker... and this is the reason why many of the most-used web APIs are REST-based... But even more than the simplicity, I appreciated the elegance of the REST approach. The basic operation and scalability of the Web has proven the underlying premise of the fundamental REST approach. HTTP operations are standardized, widely accepted, well understood, and operate consistently..
Which is a typical set of REST advantages that can be found in every REST publication, but one would expect more details from such reputable analyst company as ZapThink.
Returning back to the architectural issues, Schmelzer writes:
So, how did I meld the fundamental tenets of SOA with a REST-based implementation approach?... REST is an architectural style, not an implementation, and that the Web and the use of the HTTP protocol happens to be designed under such style.
Unfortunately Schmelzer never answered this question. He goes on talking about using the XMPP protocol, but does not really explain how two architectural styles - ROA and SOA - can come together.
Schmelzer finishes his article by saying:
I don’t believe that REST or Web Services is something upon which to take a religious stance. That being said, for the past decade or so, dogmatic vendors, developers, and enterprise architects have reinforced the notion that to do SOA properly, you must use Web Services... SOA can be done well in practice without using Web Services. The conversation about SOA is a conversation about architecture - everything that we’ve talked about over the past decade applies just as equally when the Services are implemented using REST or Web Services on top of any protocol, infrastructure, or data schema. While good enterprise architects do their work at the architecture level of abstraction, the implementation details are left to those who are most concerned with putting the principles of SOA into practice.
And so, the discussion about REST being better than Web Services continues, but there is still no evidence whether true REST should be considered as a foundation for SOA.