On Fri, Feb 19, 2010 at 10:04 AM, Markus Karg <markus.karg_at_gmx.net> wrote:
> Please see inlined.
>
> I would say this tho.. IF that is the case, you definitely want the
> consuming client to know that if they for example store the cart contents
> for a month, then come back they SHOULD do a GET call to get the URIs
> again.. and they most definitely should make sure the contents in the cart
> is still valid. This is probably outside the scope tho.. but just a thought
> I had with regards to this scenario.
>
>
>
> 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.
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.
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).
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,
-+ Tatu +-