|
Paul,
I enjoyed the article very much. It was quite thought-provoking for me, and I find I'm immediately convinced on maybe 90% of the architecture. I'm a Java kind of guy who's nevertheless been cruising down the SOAP road for a while, and now I'm wondering what really is the best solution.
I have a few questions for you, some technical and one I guess political.
1. As I understand it, if there's an Achilles heel to the REST architecture it's the inability to pass complex structures as part of a GET request. I see that just about anything can be serialized into a CGI string, but the ability to use XML would have some clear benefits, yes? It would be nice to hook JAXP code up to form a service request, instead of the admittedly trivial coding it takes to string some name=value arguments together. Do you agree that this is a deficiency of at least some magnitude? If so, what would you say is the best strategy? I would prefer an approach that could encode requests the same way every time, but perhaps the practical answer here is that for 95% of one's messages one uses a CGI string and 5% of the time it's necessary to kick over to POST/MIME, or to SOAP.
2. I like the idea of a resource-based Web extended to provide services, as opposed to the SOAP approach of returning to facades at single URIs. Both sides of this debate seem to have some claim to object-oriented bragging rights: SOAP because it fosters component-based service and REST because it is naturally decomposed into resources which might be considered Web objects with their own state and behavior. I'm not certain what my question is, I guess, but I'd be interested to hear your take on this.
3. On to the political: Edd Dumbill suggests that the W3C should get out of the Web-service specification process altogether. I see a great deal of industry momentum behind SOAP-based services. I get the sense that there will be some fragmentation between SOAP and pure HTTP services, but that the cost to the industry of failing to standardize (completely and immediately anyway) will not be terribly high -- not as bad a situation as the COM/CORBA split, for instance. As WSDL tooling catches up, and assuming that all bindings are well supported, it should be easy enough for one party to adjust to the other's choice of messaging protocols. The single-vs-multiple-URI mismatch might be a lot trickier, and data encoding is a known issue in any event.
All this to say: realistically, what do you think is going to happen?
Thanks again for a really eye-opening article.
Will Provost
|
Previous Message
