I've been thinking about the book RESTful Web Services. It has lots of negative things to say about cookies, for instance, "OK, so cookies shouldn't contain session IDs" [p. 252]. Elsewhere in the book, it describes a scheme using temporary URLs for transactions [p. 231].
I was thinking about shopping carts. If you can't use a cookie to store a session ID, then it seems natural to embed the session ID into the URL. (I'm thinking about the case when the user hasn't even logged in yet.) However, therein lies the problem. If you put the session ID in the URL, you open yourself up to well-known session fixation attacks.
Let me explain. Attacker A creates a shopping cart on a legitimate Web site that embeds the session ID (or some other sort of state) in the URL. Attacker A spams a bunch of people. A victim V clicks on the link. He knows that the site is legitimate. He adds a few things to his cart, logs in, and places the order. At this point, the attacker has the user's session ID. He can do whatever he wants with the user's account.
Perhaps I'm completely making this up. Part of being RESTful is being stateless. However, people like to have shopping carts, so some sort of state is necessary as is some way of tying a user (who isn't logged in) to that state. Perhaps there is indeed a way to maintain a shopping cart without requiring the user to log in and without using a cookie. However, naively shoving a session ID into the URL ain't it.