Re: the meaning of stateless

On 3 May 2013 03:18, "Eric J. Bowman" <[email protected]> wrote:
>
>
>
> Mike Schinkel wrote:
> >
> > 1.) Shopping cart: We have a web API that allows a user to add items
> > and the server keeps track of the items in my shopping cart...
> >
>
> ToDo: RESTful shopping cart live example using Xforms to track session
> state on the client.
>
> Roy himself endorses the client-side approach, in Chapter 6. So it's
> beyond me why all examples of REST shopping carts approach it as a
> server-side problem...
>

... probably because, in practice, that's the most practical and effective
solution to the problem and doesn't actually violate any constraint.

Its beyond _me_ why there are people describing statelessness of a client
server architecture by talking out specific types of resources..

Statelessness is about _shared state_ held between client and server.
Violating that constraint means creating an interaction that, in order to
determine its outcome, requires additional shared context _not visible in
the request_ and established by some previous interaction.

(It has nothing to do with server persisted shopping carts.)

As long as you don't create an interaction described by the above you
aren't violating the stateless constraint.

Here's an example violation:

# establish required shared context
POST /submit-search-terms
200 OK

# dependence on context of previous interaction not visible
GET /execute-search

Here's how to do the above avoiding violation:

POST /submit-search-terms
201 Location: /execute-search?id=123

# dependence on context of previous interaction visible via URL
GET /execute-search?id=123

Hope that helps.

Cheers,
M