27 January 2007 - 21:14REST and WS - part 2

I wrote a while ago a post about the differences between REST and WS. I’d like to re-visit this issue today.
I like REST conceptually, but I find it too crude. It revolves around 3 or 4 very simple operations which, its proponents claim, scale at the size of the Internet. Well, you can do pretty much everything with these simple operations, it is the value which is added to these simple operations (how you mix them up) that really matters. The packages coming out of these simple operations should scale, not the operations themselves. It is disingenious to claim that you can do everything with these operations, you can do exactly the same thing if you code in binary, but I have not seen many people advocating this for a while (even though they probably were quite a few when the compilers appeared ;-)).

The lack of standardization in REST has some subtle side-effects, one of them being, of course, the fact that you have to work extra hours because in REST you have to code by hand the interaction with a different party. In WS you can look up the webservice, invoke a code generator and immediately generate the connection to that WS, in about 15 seconds you are ready to communicate with the other party. In REST you usually get a spec highliting the URLs which serve as entry points into the other system from which you derive the communication schema and you will go off to implement it. I am sure that quite a few REST developers out there have built their own generators for building the connection with a REST-enabled endpoint, but not everyone is proficient in such tasks. WS seriously beats REST when it comes to ease of use.

I like from REST the fact that the URLs can act as a level of indirection which in turn makes customization a lot easier. Small example: user A and user B use the same URLs from the same REST service, but user A has a platinum account while user B has the bronze account. Well, the application could serve more/better data to user A (more search results for example) thru the same URL by looking up the user’s account and making up all sort of decisions. In WS you cannot do this right now, you do not have the concept of a session yet (even if WS-Conversation is being spec-ed out) and the most implementations map a class or session bean to an end point and not the other way around (you need the endpoint mapped to a process easily and not vice-versa in order for that endpoint to become a level of indirection). The good thing about WS is that when this conversational feature will get implemented it will get implemented transparently.
One bad thing about WS is the fact that it seems to have set its mind on spec-ing out every conceivable form of communication. The spec is starting to mushroom and is being stretched in any conceivable direction in order to cover every God-forsaken issue. This is obviously a problem, but I think the market will solve it. It is a pretty simple case of supply and demand: if an issue has a big demand (in other words is considered important by the majority of OASIS members) OASIS (the supply side) will produce a quality spec covering it and the app server vendors will implement this spec. If the demand for such an issue is low, then it will not get as much attention from OASIS and it will either be put on the back-burner or a low-quality spec (reflecting the lack of resources dedicated to it and the poverty of use-cases due to little input) will be produced.
As far as the vendors are concerned they will concentrate on what is business-relevant and drop the rest of the protocols, simply because they will not have the resources to implement every spec that comes out of OASIS. It doesn’t make sense to implement things your customers don’t need only because they happen to be on a piece of paper that some committe wrote (it would make a lot more sense to have third-parties implement the most obscure parts of the WS spec and have the application server vendors plug these implementations into their app servers, but this is a side thought). I think that the vendors will focus on what is mostly needed (WS-Transaction being a good example) and then delegate the rest of the spec either to a third party, which could be open source projects under the OASIS umbrella, or the recycle bin ;-). I hope that the vendor community will take this market-based approach to the WS specs comig out of OASIS, it is a very flexible and efficient approach, and not get moored in a sea of meaningless and purposeless specs.

P.S. Well, you probably got used to this by now, but this post was also written in a hurry. I’m sorry, can’t do much about it.