3510Re: [rest-discuss] Discussing REST
- Apr 2, 2003
----- Original Message -----
From: "Dave Kuhlman" <dkuhlman@...>
> First, I believe the claims about REST being state-less are very
> misleading. After all, the "S" in "REST" stands for "state". The
> server is state-less, but REST applications can have state.
The term 'stateless' shouldn't be applied to REST or applications build in
that style. HTTP as a protocol is called a 'stateless' protocol, because the
interpretation of any individual message is independent of any preceding
> just that maintaining state is the responsibility of the client,
> not the server. Another way to say this is to say that the server
> maintains no session information.
If your application or business logic requires the concept of 'sessions',
then model those sessions as resources & you should be fine. Think of it as
a 'working session' rather than 'protocol session ticket' or something. You
should be able to set down your 'work in progress' & pick it up later - even
from a different client.
> In the FSM/REST model that I use, state/session information is
> returned from the server to the client in an XML document. In the
> subsequent request, the client returns this XML document to the
> server. So, state information is passed back and forth between
> server and client.
If the resources involved are coarse-grained 'entry-points', then this is
more of a custom message-passing system, rather than using the built in
primitive/generic operations upon resources. The state information passed
should be a representation of a resource. The content should exclude
identification of any logical resource that the server should apply the
> I think you can see that the billing information could be passed
> back and forth between the server and client (perhaps in an XML
> document) until it is complete, error free, contains a valid credit
> card number, etc.
Yes, this sounds very reasonable. I'd be interested to know the
visible/addressable resource model involved.
> I think what we have done in this re-design, is to take what we
> might have called state, and turned it into a (temporary?)
I would approach it in the same way- but perhaps did you mean 'turn session
into a resource'.
- << Previous post in topic