|
You mention that "Google offers to its paid subscribers the ability to have search results published as XML". Today Simon St.Laurent pointed out on xmlhack.com that Google is embracing SOAP (I am downloading Google's toolkit to check it out), perhaps for non-paying users?
I couldn't agree with you more that the "WebService.stockQuote("KREM")" proprietary syntax will always eventually be "rendered irrelevant" by the likes of "http://www..../webservice/stockquotes?KREM", and I applaud how well you expressed this.
One of themes I see in this recurring detour pattern in the Web Services industry is that few programmers come to grips with the fundamentals of distributed asynchronous application development. So they get it done using a more RPC-style solution, or the latest much-hyped proprietary thing that seems at first to do all the work for you. But hey if they get "something" working adequately ya gotta give em credit.
Any business collaboration requires a great deal of coordination, there's no getting around it. Say Google publishes this service now, in the next go around they will improve upon aspects of it due to customer feedback.
Whether they used a REST solution or SOAP, they will probably provide new improved services at a slightly different location (a new URI in the case of REST, a new object in the case of SOAP), and phase out old versions of the service at later points in time.
But I think that on the face of it a responsible business software developer should stick with the proven and lasting fundamentals, given the opportunity. And the nice thing is that this is not something new to wait for.
We already have a de-facto universal identifier, and its a URI, and that when this wave of global identifiers and remote call syntaxes goes out of fashion like the wave before it, URIs, GET and POST will still be here.
I had more to say but when I looked back into your articles I realized you've already said it better. Great work. You are right on the mark.
|