tag:blogger.com,1999:blog-5703778183485988456.post4498203855859316497..comments2023-09-03T06:17:56.224-07:00Comments on Alan Dean: On RESTful Basket StateAlan Deanhttp://www.blogger.com/profile/05589768205632967394noreply@blogger.comBlogger10125tag:blogger.com,1999:blog-5703778183485988456.post-81745222537485050832008-11-10T13:17:00.000-08:002008-11-10T13:17:00.000-08:00Alan,You are right about my assumed preconditions....Alan,<BR/><BR/>You are right about my assumed preconditions. <BR/><BR/>The motivation for your approach, if I understand correctly, is to combine different servers into an app unbeknownest to any of those servers. Right?<BR/><BR/>In order to keep the client lightly coupled, I would still let each of these servers cooperate with other by using shared media types and links across servers. <BR/><BR/>It is possible to build a client without such cooperation among servers, as illustrated by your example. However, I think that such a cooperation promotes loose coupling.<BR/><BR/>To answer your last question on where does hypermedia start, it starts when a client starts interacting with an app through some URIs prepublished as starting points. In your example, the starting point may a search server that lets the client find some products. The rest of the URIs can come from the hypermedia. The paper I mentioned in my post today talks about this and other aspects related to discovery and descriptions. It should get published soon.Subbu Allamarajuhttps://www.blogger.com/profile/16601947707829479552noreply@blogger.comtag:blogger.com,1999:blog-5703778183485988456.post-39135924043625977072008-11-10T11:48:00.000-08:002008-11-10T11:48:00.000-08:00Subbu,My suspicion is that we are applying differe...Subbu,<BR/><BR/>My suspicion is that we are applying different preconditions to one another here.<BR/><BR/>I am applying the precondition that the basket contains generic items. Imagine a user has a shopping list of goods that they wish to purchase from a store. They can buy those goods in many different stores. The basket which describes the shopping list is not associated with any specific store.<BR/><BR/>For example, let's say that I want to buy a new Sony widescreen TV. I add the specific model I want to my basket. I can potentially purchase the basket from any one of a number of retailers.<BR/><BR/>I sense (and I accept I could be wrong in my intuition) that you have a precondition that the basket refers to items available from a specific store.<BR/><BR/>If my intuition is correct, then your approach seems to me to be more tightly coupled than mine.<BR/><BR/>I certainly agree that the checkout should be traversed by the use of HATEOAS. I didn't specify the internal behaviour of checkout in this post because it didn't seem directly relevant to the point that I was trying to make. It certainly sounds like I have another topic that I need to post about :-) <BR/><BR/>What I think that we are actually talking about here is service discovery, which is an area that has been discussed very little within the REST community (to my knowledge).<BR/><BR/>Where *does* our hypermedia start? This is an important question, not directly related to hypermedia traversal.Alan Deanhttps://www.blogger.com/profile/05589768205632967394noreply@blogger.comtag:blogger.com,1999:blog-5703778183485988456.post-6706701713661531152008-11-10T11:11:00.000-08:002008-11-10T11:11:00.000-08:00Alan,Consider the flow where the server is managin...Alan,<BR/><BR/>Consider the flow where the server is managing the basket as a resource:<BR/><BR/>- Client GETs a product resource.<BR/>- It has a link to add that product to a basket.<BR/>- Client follows that link to add the product the product to the basket.<BR/>- Client repeats the above steps.<BR/>- Product representations also contain a link to the basket.<BR/>- Client follows that link to view its current state.<BR/>- This representation has a link to checkout. It follows that link to do checkout.<BR/><BR/>In this model, the client does not know how to store the basket or what the internal structure of that basket might be.<BR/><BR/>On the other-hand, consider the flow when the client is managing the basket.<BR/><BR/>- Client GETs a product resource.<BR/>- Client creates a basket the first time and stores the product reference there. I am assuming that it will store the URI of the product.<BR/>- Client repeats these steps.<BR/>- Client finds a link to do checkout.<BR/>- Client POSTs the contents of its basket to do checkout.<BR/><BR/>The steps look short, but the client will be required to take more responsibilities.<BR/><BR/>More importantly, this model requires the client to know to how to compose the application and the workflow involved. In the model I am suggesting, the server provides the workflow via links. Consequently, the client remains less coupled to the server. Please see http://www.subbu.org/blog/2008/11/who-is-composing-your-app for more notes on composition.Subbu Allamarajuhttps://www.blogger.com/profile/16601947707829479552noreply@blogger.comtag:blogger.com,1999:blog-5703778183485988456.post-67226480073765753162008-11-09T21:10:00.000-08:002008-11-09T21:10:00.000-08:00Subbu,As I said earlier to Colin and also discusse...Subbu,<BR/><BR/>As I said earlier to Colin and also discussed in "<A HREF="http://alandean.blogspot.com/2008/11/when-basket-checkout-isn-restful.html" REL="nofollow">When Basket Checkout isn't RESTful</A>", I don't agree with the 'passing a link' approach.<BR/><BR/>How does the client store the basket state? However it likes. It's private state to the client. The only responsibility that the client has is to render the correct representation to pass to checkout.<BR/><BR/>If you want, the basket data being persisted by the client in the third diagram of this post <EM>"Client persists Session"</EM> could be in the basket format, so that when the time comes to checkout, the client simply GETs the representation from the persistence server and then passes that to the checkout. Nice and clean. The persistence server might even be a specialized basket store to save the client some work, but this is not required by the pattern.Alan Deanhttps://www.blogger.com/profile/05589768205632967394noreply@blogger.comtag:blogger.com,1999:blog-5703778183485988456.post-67880338690539617242008-11-09T19:48:00.000-08:002008-11-09T19:48:00.000-08:00Interesting. Are you suggesting that the client ma...Interesting. Are you suggesting that the client maintains the basket on its own? If so, what for does it take? As some struct that the client constructs and maintains locally without any involvement from the server? <BR/><BR/>IMO, a better model is to mode the cart as a resource itself. Looking at your other post on that, I think your example for POST /checkout can be written better as<BR/><BR/>POST /checkout<BR/>Content-Type: application/checkout+xml;<BR/><BR/><checkout><BR/> <link href="http://.../username/basket" rel="htt://.../basket"/><BR/></checkout><BR/><BR/>This is "a" representation of a resource. Here the link like a reference to another resource. If a server is ready to accept such a POST, IMO, it already implies that the server knows how to fetch the basket.Subbu Allamarajuhttps://www.blogger.com/profile/16601947707829479552noreply@blogger.comtag:blogger.com,1999:blog-5703778183485988456.post-13818411350204648972008-11-09T14:13:00.000-08:002008-11-09T14:13:00.000-08:00Sorry yeah I had read it but re-reading it clarifi...Sorry yeah I had read it but re-reading it clarified things for me.<BR/><BR/>What confused me initially was you were referring to the basket as session (application) state, but seeing your last soluton here clears things up.<BR/><BR/>I'm wondering if this isn't the way many e-commerce sites behave in practice, just looking at the form in Amazons basket page I'm thinking you do just submit them all the items (though it is late so I could be wrong). <BR/><BR/>Also it reminds me of the push/pull thing in messaging, your recommending full messages that you push rather than the pull approach which as you say might have issues. Whats interesting is my natural inclination would certainly have been to include links to the basket, if you've got URLs why not use them.<BR/><BR/>Good stuff and thanks for taking the time to write it.Colin Jackhttps://www.blogger.com/profile/01403166737046938219noreply@blogger.comtag:blogger.com,1999:blog-5703778183485988456.post-79945000083547686152008-11-09T11:04:00.000-08:002008-11-09T11:04:00.000-08:00Colin,I don't personally agree with the approach o...Colin,<BR/><BR/>I don't personally agree with the approach of passing a link as I feel that it has a number of difficulties. For more commentary on that, see my post "<A HREF="http://alandean.blogspot.com/2008/11/when-basket-checkout-isn-restful.html" REL="nofollow">When Basket Checkout isn't RESTful</A>".Alan Deanhttps://www.blogger.com/profile/05589768205632967394noreply@blogger.comtag:blogger.com,1999:blog-5703778183485988456.post-91241357619107686482008-11-09T11:00:00.000-08:002008-11-09T11:00:00.000-08:00Mike,You are correct: there would be two media-typ...Mike,<BR/><BR/>You are correct: there would be two media-types :-)Alan Deanhttps://www.blogger.com/profile/05589768205632967394noreply@blogger.comtag:blogger.com,1999:blog-5703778183485988456.post-5394570573611853212008-11-09T10:51:00.000-08:002008-11-09T10:51:00.000-08:00Alan:Thanks for taking the time to post this 'walk...Alan:<BR/><BR/>Thanks for taking the time to post this 'walk-through.' It seems one of the key points in your example here is that the *basket* resource and the *checkout* resource are not tightly bound. This makes sense to me. <BR/><BR/>What seems to be presented here are two primary MIME-types: application/basket and application/checkout. With those two types defined, I can see a great deal of serendipitous use and a big reduction in tight binding.mamundhttps://www.blogger.com/profile/12982388335427004563noreply@blogger.comtag:blogger.com,1999:blog-5703778183485988456.post-35385144410431716152008-11-09T10:29:00.000-08:002008-11-09T10:29:00.000-08:00I think I'm slowly getting it and am learning a lo...I think I'm slowly getting it and am learning a lot from this so thanks for taking the time to do it. Seeing examples definitely makes it more clear. Too few examples and discussions of tradeoffs is one reason REST can seem inaccessible or even worse can seem ridiculously simple.<BR/><BR/>Its taking me a while to get my head around this as it jars with other descriptions of RESTful solutions to this sort of thing. For example I remember Stefan Tilkov discussing turning normal "session state" into resources on the server and giving them URLs. Once you do this you can pass those URLS around so the Checkout Application would be passed a representation including a URL to the basket representation.<BR/><BR/>I think your disagreement with that approach was the layered system constraint which is not something that I've seen discussed much, will need to read more about it. Still think it must be a valid choice if all your doing is sharing a URL though, or would you really never us it?<BR/><BR/>As you say though it wouldn't work so well in smart client situations where you might well want to create a whole basket in memory and then pass it up directly.<BR/><BR/>Very interesting stuff.Colin Jackhttps://www.blogger.com/profile/01403166737046938219noreply@blogger.com