RE: Visibility (was Re: Introducing the Service Oriented Architec tural style, and it's constraints and properties.

<DB>The absence of a method implies that the URI can only be used for
one
purpose. For example a Purchase Order Processor could either, for
example:
check availability of stock and provide a response; archive the order in
an
off-site repository for later retrieval; or, calculate the tax due.

Either way, the method is their either explicity (in the URI or in the
message body) or implicity, because that is the only purpose for which
the
server at the URI can be used.
</DB>

I agree that POST is under-specified, but:
I think you're inaccurate in likening a PO as instrument of offer
to a remote procedure call.  (e.g. "check availability of stock").

Usual case:
Whether the supplier checks anything is none of the buyer's
business.  (Could be drop-shipped from a 3rd party.)

All the buyer cares about is the business response:
does the supplier accept the PO, or reject it, or
maybe wants to make a counter-offer?
(E.g., half now, half later...)

I expressed this difference at least once before.
Must not be communicating well.

A PO is not a method, it's an offer (in an offer-acceptance
business protocol that rides on top of the technical
protocol).  In the example given, POST is the method.

I think that ws-arch could provide a service
by refining the uses of POST (not including
using it to mean GET).

-Bob Haugen

P.S. you wouldn't necessarily need to use POST
for an instrument of offer.

Received on Wednesday, 26 February 2003 07:47:43 UTC