Last Battlefield
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.
Lost in the debate is real issues, like when people who should know better look the other way when HTTP GET is used for CartModify operations, or when people who don't know any better tell people how to design systems with collections on the server and cursors on the client. 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.
Obviously CartModify via GET is bad. But it's not bad because it's RPC-via-HTTP (it isn't). It's bad because it's an unsafe.
You couldn't be more wrong re the "blank line". The difference is not syntax, it's constrained vs. unconstrained connector semantics.
Posted by Mark Baker atMark, 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.
Posted by Mark at
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.
Posted by Sam Ruby at
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.
Posted by Mark Baker at
All things web
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]Trackback from Marc, himself, his blogs, and you reading them. at
Everybody who uses the Amazon API will think of the CartModify as the operation and CartID as the resource being affected.
A RESTful alternative would be to identify each cart as a separate resource, and modifications would be achieved via a uniform PUT method.
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.
Posted by Mark Baker atMark, 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).
Posted by Sam Ruby atBut 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.
Posted by Mark Baker atI'm confused, are you guys agreeing or disagreeing? If it's the latter what are you disagreeing about?
Posted by Dare Obasanjo at
Dare, we are disagreeing.
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.
It is probably best to leave them alone.
Posted by Sam Ruby atA Pretty Square Box
Here’s an issue that needs to be settled quickly. It has little to do with WS-Adressing EPRs (not that I......Excerpt from franklinmint.fm at
How many [atoms] would you like?
Google has a cool feature. It lets you tell it how many results you would like. This link will give......Excerpt from franklinmint.fm at
Ongoing Battles
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]Trackback from Sam Ruby at
Accidentally RESTful
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...Excerpt from Web Things, by Mark Baker at
REST and Web Services links
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)...Excerpt from Just Looking at
Bah.
Well, well, well. A rare overt expression of frustration from Sam. He's right, of course. Most of the so-called debates...... [more]Trackback from franklinmint.fm at