W3C home > Mailing lists > Public > www-ws-arch@w3.org > February 2003

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

From: bhaugen <linkage@interaccess.com>
Date: Wed, 26 Feb 2003 06:46:50 -0600
To: www-ws-arch@w3.org
Message-id: <001101c2dd95$223d3f20$b8eafea9@PC1>

<DB>The absence of a method implies that the URI can only be used for
purpose. For example a Purchase Order Processor could either, for
check availability of stock and provide a response; archive the order in
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
server at the URI can be used.

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

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:41:03 UTC