Please find inline.
As I said, if you *business* requirement is a service of that kind, then you
certainly can do that. But it was not clear to me that you customers expect
that service, just as I do not expect that my cart is still filled when I
come back to Walmart after one month.
It is not just what customer wants or expects. Companies absolutely want to
know much of such reservations, for various things: forecasts (for inventory
management); for search indexing (building customer behavior, not just from
purchases, but from cart additions); for recommendations engine ("people who
bought this, also..."). I would absolutely never even considering storing
most of that only on client side (or perhaps at all), for lots of business
and security reasons.
As convenient as it is to harness CPU cycles of client-side, that is just
one aspect of the whole puzzle; and requirement to scale server-side is due
to impracticality of pushing much more processing or storage to clients. If
this was not the case, we wouldn't need many of great nosql projects that
are in development.
It is not necessary to store server state to predict forecasts or do
reservations: You could model that with a special forecast API or
reservation API without storing the actual knowledge about *which* car
contains the stuff (like PUTting modified reservations states or POSTing
forecasts -- information independent of the actual cart's content). Again,
if you want forecasts and reservations, this is a *business requirement*,
and RET does certainly *not* prevent you from doing so. Remember, we
actually talked about REST's statelessness? You now are talking solely about
*business requirements*.
But beyond this, there is no universal client beyond browser at this point.
Browser can of course store cookies (poor man's client-side storage), but
there isn't much functionality beyond that.
This does not necessarily mean that other clients couldn't get written.
Efforts for creating smart/heavy clients have gone nowhere, and continue to
do so; with maybe exception of frameworks like GWT that invert control a
little bit.
This is not a problem if carts are modeled as resources, which can be
persisted by either side of conversation (and most commonly by server).
Well, there *is* a problem if carts are modeled as resources: Unless your
business enforces it, it will be an unjustified squandering of resources and
restricts your scalability by far. Remember, that this discussion was about
REST, not about business constraints? Still waiting for a technical argument
pro server sided carts (all I received so far had been business arguments).
;-)
Fat clients have their place on server side however, and this is where
JAX-RS client would be located in, more so than on leaf edge (and customer).
And that is where more complex clients are more feasible.
There is some irony in that perhaps browser-based transactions might be less
amenable to all-REST architectural style...
Could it be that impedance between stateful nature of most processes for
which frameworks are needed, and scalable architectures is not a trivial
thing to cross? Just a thought,
Totally disagree. Still did not receive a single technical argument against
statelessness, but solely business constraints enforcing storing resources
on the server side, which is *not* a violation of REST's statelessness.
Storing a cart on the server's side is *not* violation REST's statelessness
as it is not stored as part of the conversation state but as part of the
business concept. What we actually had been talking about was that a cart is
getting stored on the server side *without* a business need, so *then* it is
a violation of REST's statelessness.
-+ Tatu +-