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.
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.
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.
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.