| WebSeitz/wikilog |
| z2006-11-17- Rest Vs Soap Again |
|
| last edited by BillSeitz on Oct 6, 2008 4:53 am |
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 [POSTed] 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 Declarat Ive state style.
Each time an Offer is [POSTed] 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 [BackEnd] 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 Http Post 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?
| See Back Links: ReST | |
| User Options Recent Changes Help Page |