Re: the meaning of stateless

Mike Kelly wrote:
> 
> Holding the position that the approach is "wrong" makes no sense here
> because it is absolutely possible to design a server side persisted
> shopping cart without violating the stateless constraint, or any other
> constraint for that matter.
>

Show me.  As Mark pointed out, server-side carts share a fundamental
violation of statelessness, not shared by client-side approaches.  At
some point, a transaction is occurring on the basis of a link, rather
than transferring a representation which details the contract itself.

>
> There is no reason that a shopping cart cannot be treated and modeled
> as any other kind of server-persisted resource state. The fact that
> it is possible to model this in another way in which it is treated as
> client-side application state does not negate that.
>

True, a client-side cart may also be persisted on the server, i.e.
"save cart" or "wish list" or silently backing up the active cart -- by
transferring a representation (the Model, in MVC terms) which captures
the state of the user application, instead of passing around nebulous
links to server-persisted state.

The problem from a design perspective, is choosing a starting point
which fails to treat the cart itself as the basis for transactions;
transferring links to the contract instead of the contract itself is
not a RESTful approach allowing "the forces that influence system
behavior to flow naturally, in harmony with the system".

>
> The approach you chose is down to the context in which you are
> designing the application and one's subjective opinion. It is nothing
> to do with violation of constraints. Both approaches can be taken
> within the constraints of REST and - practically speaking - the
> capability of HTTP.
> 

One approach meets the goals of REST more than the other; if the other
even meets all REST's constraints, which is problematic.  I much prefer
examples which obviously meet REST's constraints, over those which need
to be "qualified" with convoluted explanations of why some constraint
isn't being violated when the entire approach is suspect.

Seems easier to learn REST from examples which everyone can agree are
not violating any constraints, rather than those which require the use
of imagination to get around the apparent mismatches.

>
> There are some fairly good reasons to go with this design: e.g.
> customers are then able to fill a cart from several different devices
> before checking out (fairly common behaviour), and it significantly
> improves the vendor's ability to collect, mine and analyse data on
> user behaviour around their shopping cart (vendors usually care about
> this a lot).
> 

Why isn't a client-side cart compatible with said usage patterns?  I
smell a strawman.  Discussions about vendors' desire for metrics vs.
users' desire for privacy, have no bearing on the RESTfulness of any
given example.  This list is about learning REST, not disregarding part
of it for the sake of usability/metrics while still attempting to
maintain buzzword compliance as a fig leaf.

As it is, any device can GET a representation of the user's last
application state, to continue the "session" without violating the
paradigm Mark keeps pointing out -- sending an URL for processing isn't
the same as sending a representation of the actual cart for processing.

The client-side approach bases communication on sending/receiving a
hypertext representation *of* a shopping cart -- THIS is the essence of
REST, not pretending that sending an URL for processing is somehow
stateless.  Such a message may itself be, but the point is a stateless
interaction overall -- requiring the cart itself to be transferred,
instead of linked to.

>
> You may not agree with those, but that does not mean the approach is
> "wrong" or "ignorant of constraints" in relation to REST. This thread
> is supposed to be about the meaning of "stateless", not a discussion
> on the merits of various approaches to application design.
> 

This is a discussion about statelessness, with my point being that it
would be more helpful to use examples which actually are.  It's hard to
explain the constraint using examples which arguably violate it.  Since
we're here to learn about REST, perhaps it's time we examined _WHY_ Roy
hints at client-side implementation, instead of pretending it's somehow
irrelevant to the discussion "because pragmatism".

It's easy for me to remain analytical on this issue, as I've never laid
my REST credibility on the line by selling someone a server-side cart
implementation as "RESTful" or presenting examples of same in an effort
to explain REST.  I can see where others have the motivation to insist
that their way is "right" while attempting to stifle debate about what
the thesis actually says, by declaring it an off-topic implementation
detail.

My nutshell explanation of REST from 50,000ft is that a system designed
to manipulate shopping carts MUST be based on transferring actual
representations of shopping-cart contents.  Once we're working in the
proper idiom, the constraints take care of themselves as we're not doing
anything which inherently fights against them, thus requiring convoluted
explanations to support a fundamentally different approach as RESTful.

-Eric