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, 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/
