Re: REST vs. OMA (not SOAP)

"Champion, Mike" wrote:
> 
>...
> > If you POST a logical "diff" then there is no method. The method is
> > implicitly "apply this diff".
> 
> This makes "mechanical"  sense to me in terms of manipulating resource
> *representations*, but not in terms of actual *business processes*.

You're right, and Bob Haugen made a similar point. Most likely the order
would have a URI where you would PUT or POST the acceptance so that you
have a separate document with its own URI.

> "Accepting an order" implies a lot of "functions" being called behind the
> scenes -- databases updated, entries made in ERP systems, physical atoms
> moved around warehouses and mailrooms.  It just seems like splitting very
> fine theoretical hairs to say that this should be triggered by "applying a
> diff" rather than "specifying a method" inside the POST body.

The thin hairs become thicker in a few circumstances. For instance if I
set up a business rule on object deletions but you tunnel deletions
through POST then my business rules will not trigger appropriately. I
would have to wire them in at some lower level but then I may lose
access to excellent business rules description languages like DAML.
Similarly, I lose interoperability if I tunnel GET over POST. (thus the
changes to SOAP 1.2)

If what you are doing is truly a type of POST then I don't think it
really hurts to have an "update" element and view it as a verb rather
than as a noun. But then it doesn't really hurt to think of it as a noun
and have a nice consistent architecture where HTTP defines the verbs.
What's the point of saying that for GET HTTP defines the verb, but for
POST you have to look in the message for it?

Hope that helps...
-- 
Come discuss XML and REST web services at:
  Open Source Conference: July 22-26, 2002, conferences.oreillynet.com
  Extreme Markup: Aug 4-9, 2002,  www.extrememarkup.com/extreme/

Received on Thursday, 18 July 2002 17:28:56 UTC