Google’s choice [of SOAP] was technologically poor… I will show that a Google API based on XML, HTTP and URIs can be simpler to use, more efficient, and more powerful.
I think that what goes over the wire is nowhere near as important as the fact an interface to a popular Web application now exists.
There’s a lot of SOAP backlash these days. … The claim that SOAP is bad because the wire format is ugly and hard is like claiming nobody should use Pentiums because their instruction sets are so much more complicated than the instruction set for the 8086. Yeah, it’s true, but we have compilers that take care of that.
Of course, Joel goes on to say:
The real problem with SOAP is that it’s a completely inadequate remoting system. It doesn’t have events (which makes it useless for large classes of applications). It doesn’t support references (ditto). It has about 10 years to go before it gets to where CORBA and DCOM were 10 years ago. And we’re supposed to be all excited about this because we can sneak through the firewall. Gee, I wonder what the firewall vendors are working on these days? As soon as they’re done, we’re even further back than we started.
Note that these are not arguments for REST instead, since REST has the same limitations. Joel wants something that doesn’t exist (and may never exist): an enterprise-level distributed object system that’s platform-neutral, vendor-neutral, language-neutral, patent-free, and that enjoys wide industry support. Lots of luck with that. Meanwhile, pundits will keep having these pointless little flame wars about wire protocols, and programmers will keep scraping HTML pages because 99.99% of the information we want is only exposed through web pages anyway.
Later:
The excitement about google’s API is the fact that it’s inviting programmers to use it openly.Agreed, which is why I was so disappointed to learn that Amazon’s XML interface is only for associates.
The real reason to forget about REST is: native types. I don’t want to have to read documentation, figure out a format, and then write a function to parse every separate web service individually. I want to *call* a function and get my results as an array, damnit.
How do you think developers will make use of web services? Just another way to add functionality to an app? “Glue” to tie “other” things into a web site? Fundamental business solution? All of the above? Something else?Mostly glue.
The web services that are available already (Google, Amazon, Blogger, Manila) are already web-based businesses, so they’re the pioneers. Most businesses only got on the web a few years ago, and only because they were forced to by more powerful companies in their supply chain. Once those big players start saying “we need 24-hour real-time access to your inventory so we can streamline our purchasing decisions, here’s a WSDL file, get to it”, you can be sure there will be a sudden surge of interest in real-world web services expertise that makes the current hype bubble look tame.
Play with these fun little toys now. Play with every variation, every protocol, every format, so no matter which way the wind blows, you can say “sure, I’ve been doing web services for years now” in interviews next year.
§
I am no longer accepting public comments on this post, but you can use this form to contact me privately. (Your message will not be published.)
§
firehose ‧ code ‧ music ‧ planet
© 2001–8 Mark Pilgrim