Anne,
Just to confirm something that you and Pete have mentioned before, the
reason you are using POST instead of PUT to submit the order is because
the server is choosing the URI and not the client?
Regards,
- Anil
________________________________
From: [email protected]
[mailto:[EMAIL PROTECTED] On Behalf Of
Anne Thomas Manes
Sent: Thursday, June 07, 2007 8:52 AM
To: [email protected]
Subject: Re: [service-orientated-architecture] Anne on REST
(Time for Spring WS v. REST Campaign to Open)
To be a bit more specific:
Resources have state. To ask the server to maintain state, you
create a new resource. But every interaction is stateless, therefore the
client must reestablish its state on each interaction -- by referencing
the resources (URIs) that maintain the state.
In an order processing system, you might have a resource called
http://example.org/orders. To submit an order, you POST your order to
http: example.org/orders <http://example.org/orders> , and it creates a
new resource called http://example.org/orders/123. To get the status of
the order, you GET http://example.org/orders/123 . To update the order,
you PUT the revise order to http://example.org/orders/123. If you want
more granularity, you can POST an order, then POST line items to your
order.
Obviously the server is maintaining the state of submitted
orders, but it is not maintaining session state. Each time you interact
with the server, you must specify which order you are talking about. The
server does not retain the knowledge that when you interact with it you
want to work with the 123 order.
Anne
On 6/7/07, Stefan Tilkov <[EMAIL PROTECTED]> wrote:
On Jun 6, 2007, at 11:50 PM, Steve Jones wrote:
> Can you give me an example of an order processing
system which is
> completely 100% RESTful (i.e. retains no state
whatsoever) I'm
> finding it difficult to envisage an order processing
system that
> doesn't remember the orders submitted.
That's a misunderstanding - REST rejects _communication_
state, not
state in general (which is supposed to be exposed via
resources).
This kind of "statelessness" has been good practice
since the days of
CORBA (at least in the systems I was involved with).
Stefan
--
Stefan Tilkov, http://www.innoq.com/blog/st/
