Re: the meaning of stateless

On Sat, May 4, 2013 at 2:41 AM, Eric J. Bowman <[email protected]> wrote:
> Mike Kelly wrote:
>>
>> Shopping carts are better off on the server side, so a client side
>> shopping cart is a horrible thing to use as an example because it
>> immediately conflicts with how people need to build stuff in practice.
>> Just pick another example that's a bit more realistic, like a
>> multi-step wizard or something.
>>
>
> Sorry, but I'm going to go with Roy on this one, developers' perceived
> "need" to do it the wrong way aside.  People build stuff wrong in
> practice, usually in blissful ignorance of REST constraints, but this
> doesn't make the wrong approach "more realistic" it just means the
> right approach is completely misunderstood -- making it an ideal
> example.
>

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. 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. 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.

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).

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.

We should probably get back on topic.

Cheers,
M