[
Lists Home |
Date Index |
Thread Index
]
Hmmm.
On Tue, 6 Jan 2004 15:49:37 -0500
Elliotte Rusty Harold <elharo@metalab.unc.edu> wrote:
> At 1:47 PM -0500 1/6/04, Amelia A Lewis wrote:
> >In order to make it easy, I *also* need to use GET as often as
> >possible, so that the customer can freely hit the Back button without
> >getting the irritating "oh, you wanna buy another one, do you?"
> >dialog box. The few places where I've got POST (because the action
> >isn't idempotent), I also provide a special button (php constructed)
> >that performs an action equivalent to back (go back to the middle of
> >the list that you were just looking at). Amazon, btw, seems to add
> >to the cart without using POST, which always struck me rather oddly.
>
> This is a very tricky case. I've had to think about it for a while,
> and I think it's doable. The key is that you give every shopper a
> cart, almost no matter what. The first time they hit your site at
> http://www.store.com/ you immediately redirect them to
> http://www.store.com/cartid/ where cartid is randomly selected
Okay. So how is this different from http://www.store.com/sesssionid/ or
http://www.store.com/?sessionid ?
Well, apart from the fact that such URLs are less shareable?
> identifier string. Internal URLs should all be relative off of the
> /cartid/ base. This will make it easier to keep track of the cartid
> without having to do lots of dynamic rewriting of pages. Your
> database keeps track of what they've purchased in the usual way by
> matching cartid to a list of items they've added to their basket.
> Once they do log in to purchase, you can either assign cartid to
> their user name permanently or just swap the baskets on them.
Isn't this just sessions, using URL rewriting? Why should I write
sessions-enabling code instead of using a mature package that does it
for me? What does this buy me?
If the fact that the path is rewritten, rather than a query string, is
the key that makes this RESTful, why should I regard it as an advantage?
Now, even for simple pages-to-view, the session (or cart) id is
exposed.
The package that I use prefers cookies (because then the URLs can be
shared), but falls back to URL rewriting when cookies are disabled (I
haven't actually tested that, though ... suppose I ought to).
> I'm not perfectly happy with this, and I won't be surprised if you
> poke holes in it. The biggest problem I see is that I'd like the main
> page not to redirect. Possibly, you could make the main page not
> redirect, and have all its URLs rewritten to point to the randomly
> chosen cartid. Then use /cartid/ with relative URLs from that point
> forward.
In fact, there are quite a number of pages that are really static, that
provide value-add to the site rather than offering items for sale.
Typical small business site, really (at least, typical when the customer
base is known and the site provides some degree of "community" feeling).
> There may be a cleaner solution I haven't thought of yet. I do have
> one that might satisfy you, though it doesn't quite meet your
> criteria. What if registration were less onerous than usual? In
> particular what if the login page accepted non-registered usernames
> and passwords, and immediately registered them? i.e. login equals
> registration?
Hmm. I think that I would have to ask my client, but I feel fairly
certain that they'd reject it out of hand. *I* would, if I were running
a commerce site (that's in part because I generally won't buy from a
commerce site if it asks me to identify myself first, with a very few
exceptions; I won't try to force on someone else what I won't accept
myself). An analogy, since I think you're in NYC: would you accept it
if, in order to enter a store on Avenue of the Americas, you had to show
identification?
Note that the site I have in mind uses immediate-expiration sessions
(expire when the browser closes), and no "accounts" at all. At a later
date, the client might want to add optional account creation (for
customers who prefer that), and that would prolly use http auth and the
existing mysql store.
As it stands, I set a session cookie, which is a very small amount of
state, that leaves the sharability of URLs very high, and store other
information associated with the user into the session store. I
understand that this is not RESTful, but is it because the whole idea of
e-commerce is not RESTful? Is it the case, then, that we shouldn't be
using HTTP for e-commerce?
> There should be a cleaner solution though. I'm pretty sure the
> shopping cart should be a resource and that it should have a URI of
> its own. And I agree that you shouldn't have to POST into the
> shopping cart. I'd like to think that this could be done without
> rewriting every URL, but the problem I keep bumping up against is
> that there are separate resources for the general public pages and
> the shopping cart, and HTTP normally doesn't want to see more than
> one resource at once. I need to give it some more thought.
Please do. As I said, in my initial challenge, I have heard it stated
that REST can do everything that the state-oriented session-saving
(cookie-loving, but not cookie-dependent, since URL rewriting works too)
style can do, but I've never seen it actually explained in a way that
appears to work for the problems I commonly encounter.
Amy!
--
Amelia A. Lewis amyzing {at} talsever.com
Love?
A joke, that. Love was the problem, not the solution. Being hit by a
car was better than love.
-- Steven Brust, PJF, "Cowboy Feng's Space Bar and Grille"
|
