tag:blogger.com,1999:blog-5703778183485988456.post8232857500015278968..comments2023-09-03T06:17:56.224-07:00Comments on Alan Dean: When Basket Checkout isn't RESTfulAlan Deanhttp://www.blogger.com/profile/05589768205632967394noreply@blogger.comBlogger5125tag:blogger.com,1999:blog-5703778183485988456.post-28170957627712017822008-11-09T08:59:00.000-08:002008-11-09T08:59:00.000-08:00Colin,I have just posted "On RESTful Basket State"...Colin,<BR/><BR/>I have just posted "<A HREF="http://alandean.blogspot.com/2008/11/on-restful-basket-state.html" REL="nofollow">On RESTful Basket State</A>" which will hopefully cast more light on your question.Alan Deanhttps://www.blogger.com/profile/05589768205632967394noreply@blogger.comtag:blogger.com,1999:blog-5703778183485988456.post-54568943213385236552008-11-09T07:17:00.000-08:002008-11-09T07:17:00.000-08:00Colin,I suspect that you are missing the point tha...Colin,<BR/><BR/>I suspect that you are missing the point that I am making, that <EM>"Somewhere, a token is being kept that <STRONG>links the user to the session state on the server</STRONG>"</EM>. The token is not the important part. It is the link to session state on the server that is the problem.<BR/><BR/>In the next post "<A HREF="http://alandean.blogspot.com/2008/11/what-restful-basket-checkout-might-look.html" REL="nofollow">What a RESTful Basket Checkout might look like</A>", I discuss this issue. The example I refer to is <EM>"You might, for example, have requirement to remember the last basket state in order to highlight previous purchases."</EM> but basket persistence across a period of 6 months is equally valid.<BR/><BR/>I have no problem with the basket data being kept on a server. The problem is keeping it in session within the context of the 'checkout application'.<BR/><BR/>Sounds like I need to write another post to drive into this in more detail. I'll try to put that together this afternoon for you.Alan Deanhttps://www.blogger.com/profile/05589768205632967394noreply@blogger.comtag:blogger.com,1999:blog-5703778183485988456.post-57014241268896869222008-11-09T06:38:00.000-08:002008-11-09T06:38:00.000-08:00"Somewhere, a token is being kept that links the u..."Somewhere, a token is being kept that links the user to the session state on the server"<BR/><BR/>Is this always session state though?<BR/><BR/>If I look at Amazon my basket has real meaning, I can add things to it, go away for 6 months and come back and they are still there. <BR/><BR/>Could this not be seen as making the basket a really meaningful resource in its own right?<BR/><BR/>"Then I don't consider this to be RESTful either because there is no representation being exchanged with the server by the client."<BR/><BR/>Just thinking of Amazon, from the point where you submit your basket there are multiple POSTs before you complete the request. Along the way you specify multiple values (resources?) such as address details, whether to gift wrap (and other misc) to payment details.<BR/><BR/>Thinking of designing RESTful WS around this I'd be considering having you submit (PUT) one OrderPlacementInformation resource (no idea on terminology) which had those details and reference to the basket. <BR/><BR/>The result would be the creation of all sorts of other resources and in particular an Order, we would also update existing resources such as the basket itself.<BR/><BR/>Just an idea, be interested in your views.Colin Jackhttps://www.blogger.com/profile/01403166737046938219noreply@blogger.comtag:blogger.com,1999:blog-5703778183485988456.post-23248035110964826212008-11-07T11:42:00.000-08:002008-11-07T11:42:00.000-08:00What I should also have mentioned is that it breac...What I should also have mentioned is that it breaches the Layered System constraint (because the server has knowledge of the client persistence store). In the next post I discuss the use of a 'personalized resource' which doesn't breach this constraint.Alan Deanhttps://www.blogger.com/profile/05589768205632967394noreply@blogger.comtag:blogger.com,1999:blog-5703778183485988456.post-53727770893886641932008-11-07T11:31:00.000-08:002008-11-07T11:31:00.000-08:00Started writing a long comment, but it can be summ...Started writing a long comment, but it can be summed up as:<BR/><BR/>Is the uri identifying a resource a valid representation of such resource?<BR/><BR/>text/uri-list is a valid representation of a uri. And webarch doesn't help us much for this:<BR/><BR/>A representation is data that encodes information about resource state.<BR/><BR/>What happens when the uri (or uri-list) is received by the server? If we accept that such representation is indeed valid for our resource, then the server can attempt to dereference that uri, a process that would be by definition very quick in the situation where it issued such uri itself.<BR/><BR/>Is it reasonable for the server to reply that it is a client error to send a Uri not issued by that server? Woudl it still be restful? Backtracking the questions that arised around amazon s3's use of copy may be of interest.Sebastien Lamblahttps://www.blogger.com/profile/17767644235013483199noreply@blogger.com