RE: Dead trout

One may argue that the purchase order that a buyer makes and the purchase
order the a seller fulfills are two different resources.

As the seller's copy of the purchase order is being processes it's state is
changed. The buyer's copy remains intact. Based on the definition of
resource as explained by Roy, these are two separate resources (different
RM(t) functions). In other words, if I PUT the purchase order in multiple
places these are distinct resources (which I assume we don't have an
argument abount).

Since I am interested in determine whether the purchase order is PUT in
order to be logged, PUT in order to be reviewed, PUT in order to be
processed, etc I need additional meta-data (also something REST talks
about). The meta-data is identical for two same services (audit service X
and audit service Y), and different for two different services (audit
service X vs fulfillment service A).

So in REST terms the HTTP protocol is used in the same way to put/post that
data, and for crying out loud I can't see why PUT is better than POST in
this case.

Also in REST terms additional meta-data is required and by abstraction could
be defined to be identical for X and Y and different for X and A, e.g. by
capturing the semantics associated with the place at which it is posted.
Which is something WSDL operation definitions accomplish.

So perhaps WSDL is RESTful after all?

arkin


> Let's think about what is actually happening here
> in business semantic terms.
>
> The most common business protocol for orders is Offer-Acceptance.
> In that protocol a Purchase Order is an offer to buy.
>
> A good reference is UNECE Recommendiation 31,
> Electronic Commerce Agreement:
> http://www.unece.org/cefact/rec/rec31/rec31_2000_00tr257.pdf
>
> UNECE calls a PO an Instrument of Offer.
> Could be a Web resource, PUT or POSTED.
>
> The supplier is not obligated to accept the offer.
> Whatever steps 1 thru 6 that the supplier takes
> in preparation to respond is not necessarily any
> of the buyer's business.
>
> Then in UNECE terms, the supplier responds
> with either an Instrument of Acceptance or Rejection.
> Which could also be a Web resource.
>
> If the supplier accepts, the trading partners have
> formed a contract (let's call it an Order) which
> could alsu be a Web resource.
>
> So the whole Offer-Acceptance protocol could be
> accomplished quite nicely in a REST architecture,
> or also in an EDI-mailbox-style SOAP architecture.
>
> -Bob Haugen

Received on Wednesday, 19 February 2003 15:17:14 UTC