Loading ...
Sorry, an error occurred while loading the content.

3510Re: [rest-discuss] Discussing REST

Expand Messages
  • S. Mike Dierken
    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

      > It's
      > 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
      information against.

      > 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?)
      > resource.
      I would approach it in the same way- but perhaps did you mean 'turn session
      into a resource'.
    • Show all 6 messages in this topic