Following up with the Amazon announcement of their REST XML API (way too many acronyms in that description), there's a bunch of commentary about the Amazon/Google dichotomy. (Some of this was presaged in Matt's journal last week.
From Edd's weblog:
The frenzy over Google's new SOAP API is just plain silly. Today I was sent details by a proud PR representative (I'll not mention them, but you'll likely hear from them yourselves) of his company's Google-over-email service, using the SOAP interface. What a waste of space for something that can be done in one line of shell script!From Simon's weblog, about patents and SOAP:
However you feel about the technical merits of Web Services or REST, it seems pretty clear that REST is a critical option that offers developers an apparently safe harbor from intellectual property claims.And another tidbit from Simon, just pointing to the original xmlhack article.
Naively, it seems to me that SOAP may be bigger and uglier and less scalable, but it has the big advantage of behaving like a function call. I remain unconvinced that returning a document is useful--returning a data structure is. And most languages don't have the delicious XML::Simple option of converting between documents and data structures easily.
Rant ends.
--Nat
Re:SOAP v REST
ask on 2002-04-19T03:18:50
Maybe I am missing something (not so) obvious, but if you ignore all the wanking then REST is just "do it with normal HTTP calls".
You are right about there not being a neato standard for encapsulating the data. However, for most applications that's really simple. In Perl anyway.Re:SOAP v REST
gnat on 2002-04-19T04:35:13
I think I finally worked out why I don't like returning arbitrary XML documents as much as I like returning SOAP responses. Each arbitrary XML document hides the information you want in a different way--what's the tag, how far down is it, is it in the attribute or the contained text,... ? In SOAP it's a return from a function call--it might be a scalar or a list or a hash, but that's all it'll be. It just seems like extracting information from an arbitrary XML file is not *that* much better than extracting it from an arbitrary HTML file! Either you use TokeParser or TreeBuilder or you use SAX or DOM. It might be marginally less chaos in XML, but only marginally. Brittleness is only one order better--if the XML schema changes, your program has to change too.
So I see REST as a step better than screen-scraping, but still nastier than SOAP.
--Nat
Re:SOAP v REST
Matts on 2002-04-20T18:21:38
The only difference is that with REST you need a specification to find the info.
Oh wait, you need that with SOAP too...Re:SOAP v REST
gnat on 2002-04-21T22:08:49
"specification"? You mean WSDL?--Nat
Re:SOAP v REST
Matts on 2002-04-22T06:12:37
No. WSDL tells you what the API is, not how to use it.Re:SOAP v REST
darobin on 2002-04-24T04:36:44
There is a lot of wanking going on in those debates. As I'm not a heavy XML-based RPC user and haven't been able to extract more than simple truisms from either sides' continuous babble I've decided I'll wait until the dust settles to see what can be learnt. It might not settle just enough this time around, in which case we'll have to wait until both sides have more experience with their choices.
So far the best I've extracted from the whole debate is that my theorem according to which the clarity of a debate (and of the minds of those that take part in it) can be measured as inversely proportional to the number of posts per day on xml-dev has been empirically verified once again.
Re:SOAP v REST
ziggy on 2002-04-24T13:17:14
Why didn't you mention that before I got dragged into that quagmire?So far the best I've extracted from the whole debate is that my theorem according to which the clarity of a debate (and of the minds of those that take part in it) can be measured as inversely proportional to the number of posts per day on xml-dev has been empirically verified once again.:-) The best summary I can muster from the proceedings is this. Apologies for the length.
RESTful Chorus: There's something amiss with SOAP: since everything is a POST request, no information found behind a SOAP interface is addressable via URI.SOAPful Chorus: So? Is this a problem?
REST: Yes. SOAP hides data from the web. You can't locate SOAP-centric information within an <a href=""> tag, describe the resource within an RDF statement, pull it in within XSLT, or use it in any number of other important ways!
SOAP: So?
REST: SOAP is broken. It's not web-based. "Web Services" is a misnomer if it can't be used on the web.
SOAP: So you're saying SOAP is broken? No it isn't. There are <sagan>billions and billions</sagan> of SOAP implementations in the Fortune 1000 today used for mission critical apps. Furthermore, SOAP has always worked for us.
REST: No, SOAP isn't broken. Many of us prefer XML-RPC, but SOAP is OK. What's broken is that SOAP isn't idempoent.
SOAP: What do you mean by "impotent"?
REST: Services should be using GET instead of POST when possible. Then you can do things like cache requests and pour over access logs.
SOAP: You mean we should use GET requests? But they are soooo broken. And you can't say very much in a URL. And you can't post structured data. (Aren't we supposed to be using XML for this, instead of hacking together URL parameters?) You must be crying over spilt milk or something. Please go away. We've won already. Stop trying to invalidate our victory.
REST: No, this is very important for the functioning of the Web. Google used to have a true web service that was HTTP-GET based, but they took it a way and made a very bad decision to make it a SOAP service. That evil company Amazon is doing the right thing by providing an HTTP-GET based service for their associates. Look at what Amazon did and Google used to do -- they did it right! Furthermore, most SOAP requests are nothing more than passing a few parameters to a service. They might as well be HTTP-GET services using a proper REST foundation!
SOAP: Stop crying over spilt milk. We won. Get over yourselves. Roll over and die already. We need to move forward.
REST: But you're just smoke and hype!
SOAP: So? We're shipping production systems . You're being shrill and spouting meaningless academic theories.
Re:SOAP v REST
jhi on 2002-04-24T18:59:35
Wank all you want but many people are of the mind that SOAP was and is a bad idea: try this for a size. The virtue you quote (behaving like a function call) is a minus to other people (who would prefer, say, more asynchoronus, or more broadcasty, or whatever, style for building distributed applications.)
