(2006-11-17) Rest Vs Soap Again

Multiple links on ReST vs SOAP. Nelson Minar says As someone who bears some past responsibility for well used SOAP services (Google's APIs for search and AdWords) let me say now I'd never choose to use SOAP and WSDL again. I was wrong. Some amount of this is driven by Duncan Cragg's series on the same subject.

Duncan's setting piece sets up for more complicated functions. This is one of the Myths of ReST - that it's just for simplistic reading and writing of data. It's a actually a myth that's often propagated by the ReST community itself, especially with their over-emphasis on the Four HTTP Verbs, which seem to map so conveniently onto Create, Read, Update and Delete (CRUD).

Jan'2007 update: Duncan gives examples of more complicated functions.

• The trick is simply to identify your resources, then to discover or define how their state depends on related resources and P O S Ted content, using transformation rules, or "animation" code... OK, first identify your resources: let's look at what resources are implied by your list. You mentioned Place Offer, Respond To Best Offer, Complete Sale, Send Invoice. So, it looks like we have this list of resource types: User, Item, Offer, Response To Best Offer, Feedback, Invoice. Notice how, when we go from function (Respond To Best Offer!) to resource (Response To Best Offer), we change the names from an imperative instruction style to a Declarative state style.

• Each time an Offer is P O S Ted referring to an Item, the target Item itself is updated. In particular, the Item has a sub-container with a list of current Offers on it, ordered by value. That sounds like we're getting too far into Back End stuff here, and not in a good way (what is this, a Hierarchical Database?),

• Sam then POSTs a Response To Best Offer, accepting, and linking to, Bill's Offer. Does the HttpPost go to a '/Offer' or to '/Offer/12345' or something else?

• Yes, instead of calling functions, we're asserting state and then applying rules to bring the state into a configuration consistent with those rules.... Always remember, though, that an Item is responsible for its own integrity - it may change spontaneously according to its internal transformation rules, or may change directly via User POSTs - but only if it will be consistent with its internal integrity rules. Wow does anyone write code that way? Or is this just a complicated way of describing what everyone does?