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

REST PO example

From: Mark Baker <distobj@acm.org>
Date: Sun, 18 May 2003 23:09:57 -0400
To: Anne Thomas Manes <anne@manes.net>
Cc: www-ws@w3.org
Message-ID: <20030518230957.N21062@www.markbaker.ca>

On Sun, May 18, 2003 at 09:26:27AM -0400, Anne Thomas Manes wrote:
> So let's carry this example to something a bit more applicable to the real
> world. Let's say order processing. The traditional SOA folks (i.e. RPC
> heritage) would normally create a single service with a single URI that
> exposes about 20 operations to do all kinds of things with orders. Users of
> this service must include the PO ID number with all calls and they must
> indicate a method name indicating what should be done.

Sounds about right.

> In a RESTful example, you would have a different URI for each PO number. You
> use the "new PO" URI to obtain a new URI for your PO. Then you use PUT on
> the PO URI to submit the order, and GET on the PO URI to return it's state
> (the PO plus its current status). Another PUT would submit changes.

Not exactly, no.

I'd make sure each PO, once processed, had its own URI, sure.

I'd also have a URI which identified a "PO processor".  If some third party
had an XML PO document, it could POST it to this processor to initiate the
purchasing process, and perhaps receive a 201 response with the Location
header providing the URI of the current status of the PO.

I don't see a use for PUT in this example, unless we wanted to support
changing POs after they were submitted.

> Okay -- that takes care of the basic CRUD operations -- but order processing

Well, as I responded to Mike, REST isn't CRUD, it's more than CRUD.
CRUD is only for direct data manipulation.  REST is for data
manipulation and processing;

http://lists.w3.org/Archives/Public/www-ws-arch/2003May/0101.html

> involves a lot more than CRUD operations. So please, Mark, can you provide
> us a real-world example? One that lets us do thinks like aggregate
> information about orders by customer, back order status, payment terms,
> geographical region, etc?

Using the PO example above, there's lots that could be done.  Let's
say that there was a container of POs at http://example.org/po/.
One could define a URI-based query over that container which would
identify orders by customer, by back-order status, etc..  So some
sample query URIs could be;

  http://example.org/po/?custid=234343
  http://example.org/po/?status=bo
  http://example.org/po/?region=ca

MB
-- 
Mark Baker.   Ottawa, Ontario, CANADA.        http://www.markbaker.ca
Web architecture consulting, technical reports, evaluation & analysis
  Actively seeking contract work or employment
Received on Sunday, 18 May 2003 23:07:36 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 3 July 2007 12:25:42 GMT