1 June 2007 - 14:26REST and WS - part 3

I was reading this article on infoq about REST winning in front of WS. Rather than REST gaining ground I see this as a split in software development environments. The fact that Amazon, eBay, etc… are using REST doesn’t validate REST as a technology, it simply opens up Amazon’s IT infrastructure to a group of people that cannot/don’t want to use WS. This group of people is made up of PHP coders, PERL hackers, possibly Ruby and Python developers. This group of people doesn’t use WS, they are not even present in the WS specification process, they tend to ignore it. I am not sure about the reasons for this attitude, it has to do a bit with lack of resources and a decentralized decision making environment (I am not sure that the PHP or Python community can be a part of the WS process, these communities are usually not part of standard bodies *), a bit with the fact that the apps they are working on don`t need WS capabilities (I`d be surprised if your typical PHP bulletin board needs transparent security certificates exchange or long-running transactions) and probably a bit more with ideology. REST is remoting for small, LAMP, webby applications, WS is remoting for enterprise applications and their differences are the result of different needs and resources dedicated to these needs rather than some fundamental difference in architetural styles.
So rather than seeing this shift in REST and WS usage as a validation or invalidation of one style or another I see it as as split in the development environments. WS will very likely be confined to JEE and C#, basically it will be used for enterprise development and communication within this environment. REST will be used for deployments facing heterogeneous clients since REST is adopted and accepted by pretty much all the hackers/coders out there (if a PHP guy can agree with a Python guy on something is that REST is good and WS is bad).
So applications will be remoted differently based on the client to which you are exposing your application. If this split will do anything it will make the remoting of an application a process de-coupled from the application itself and coupled more to the remoting environment (REST/WS/RMI, etc…).

Remoting an application should be thought from now on as a transparent process which should be applied to an application transparently. This should have been done anyway, but the REST/WS split probably brings the point home a lot harder.

P.S. There is a big architectural difference between REST and WS, namely REST deals mostly with exposing state and its associated operations (CRUD) while WS deals mostly with exposing business logic. If I am correct REST can be thought of as a way to remote the data-layer, while WS as a way to remote the business logic. With REST the business logic layer is to developed on the client side, while WS gives it up-front. I think this is a pretty serious limitation of REST, the fact that you have to re-code the business logic in different environments is an effort which is not to be underestimated. But with REST you have control over your business logic and the possibilities for mashing up a different client are greatly enhanced.
WS can also remote the data layer, it would treat the data layer as another business concern that has to be exposed, so in this respect WS is more powerful than REST (it can implement REST-specific functionality if it wants to).
Again, the split between REST and WS is a split in development environments due to various market forces playing out in the IT landscape and not a debate about the efficiency of one style vs the other.

* I wonder if the famous get method of the REST architecture is symbolic of the relationships in these communities, it appears as though the Perl/PHP/Python communities can agree only on the lowest-common denominator. How more common and generic can you get than get?