Like the
StarTrek episode where a planet of bichromatic beings find some
other absurd differences to justify their prejudices and hatred,
the debate between SOAP and Rest
rages
on. The central issue often boils down to whether or not
query parameters are before or after a
blank
line. Bah.
The difference in how
these terms are used is a symptom. The underlying root
cause, however, is fundamentally differing definitions of the one
word "simple" ranging from "hiding the details that are not
important to me" to "has the fewest number of moving parts", and
people conflating the two.
TCP/IP is an example of a system with many moving parts that
achieves simplicity by hiding details that aren't important to
people. HTTP is an example of a system that achieves
simplicity not by hiding details but by having few moving
parts.
XML and SOAP attempt to find middle ground between these two
definitions, with varying degrees of success.
Bah.
Well, well, well. A rare overt expression of frustration from Sam. He's right, of course. Most of the so-called debates......
[more]
Mark, there's no use arguing with him. He's been fixating on the "blank line" for over three years, and he will no doubt go on repeating it for another three. The last time we did this, I called it the "Swift Boat Veterans for SOAP" position. Perhaps now we can modernize the analogy to USANext? Whatever. He's just jealous because he needs RESTagra to have a good time.
To me, the key question is: what is the operation? If the intent is to retrieve the representation of a resource, then the use of HTTP GET is both correct and ideal, as we do indeed have uniform semantics. If, however, the intended operation is CartModify, then what we actually have is custom semantics, independent of whether that information is placed inside the URI, inside a SOAPAction header, or is buried inside of the payload.
Exactly the right question, Sam. Now take a URI with "operation=ModifyCart" in it, hand it to somebody technical who isn't familiar with Amazon's APIs, have them put it in the browser bar (or pass it to wget/curl) and ask them what operation they just invoked.
Some recent wow-experiences in the web-browser: bookmarklets at work in relation to googlemaps. (via Sam) ajax (via tomk) And closer to home the fine HTMLArea wysiwyg editing experience integrated with the features of our daisy cms and related to it:......
[more]
My mother wouldn't be using the Amazon API when she clicks on an Amazon WS URI. All she knows is "url in the browser bar, hit enter, see data". That's the only contract she - and her browser - understands, so neither of them can possibly be a party to any Amazon specific contract.
I agree that the "CartModify" operation is being invoked. But that's not the same as it being part of the contract.
Mark, with all due respect, your mother wouldn't be using the Amazon API. Period.
The contract for CartModify is spelled out here. It is not intended to be used by your mother via the browser bar. It is not something that should be cached by HTTP proxies. It is not something that can be retransmitted automatically as it is neither safe nor idempotent.
The contract specifies how resources (carts) are to be operated on (modify) by placing both in the URI. Correct usage of this contract requires a bit of coordination (a series of interactions) and requires a shared understanding of the current state of the carts.
A better approach would be to identify the cart as the resource via a URI. Uniform operations would include GET (retrieve a representation of the cart resource), and PUT (replace the resource).
But that's my point, Sam, my mother doesn't know the contract, yet an action she takes has the same result - the cart is modified - as somebody who does.
I agree that the GET/PUT solution you describe would certainly be more RESTful when it is the intent of the message sender to set the state of the resource. My mother has no such intent when she places that URI in the browser bar.
Thinking about it some more, in some ways, I got my analogy entirely backwards. Analogies are sometimes funny that way.
Those of us in the real world use a mixture of GET and POST requests. GETs for retrieval. POSTs for updates. My weblog works that way. Some systems, like Subversion and Microsoft office, actually use some additional verbs.
But every once in a while we encounter some rather strange creatures. Ones that feel that it is entirely reasonable to define interfaces like GetCultures which are only accessible via POST. Ones that feel that it is entirely reasonable to define interfaces like CartModify which are only accessible via GET.
These beings seem destined to fight with each other until the end of time.
In the Web services vs REST debate, there are no winners. It doesn’t matter anyway, the real winners are SMTP and BitTorrent. Truth is a web page dated 1969/12/31. You are the enemy you have to defeat. We are the new MSM. We like to link to...
[more]
I’ve talked about both the pluses and minuses of Amazon’s approach to Web Services for some time now. Recently, I’ve heard that they’re in the process of greatly expanding those services, which is great. But I think that before they go too far with...
I’ve been doing some research into REST and web services. Here’s some links I found helpful. Paul Prescod: Common REST Mistakes (Date unknown) Sam Ruby: Shades of Grey (Sept 2002) Sam Ruby: Vacant Space (Sep 2004) Mark Pilgrim: RESTagra (Sep 2004)...