I'm building a Portal using the REST way. In this portal there are some shopping features. For sure we have then the usual suspects: the catalog and the basket. I have portlet to show product list, product detail and to interact with the basket. Some product can be added directly to the Basket while others should be configured first (choosing some options)
I'm currently wondering about the REST side of this. I consider working with different resources... (hey, it's REST) Consider the user is Louis, and he want to buy a ball that exists in three colors. So Louis should be able to add the ball in his basket after having selected the ball color (trust me, my case is more complex than that) So, conceptually, http://site.com/users/Louis should be able to add a http://site.com/products/ball to the basket http://site.com/basket/Louis. Right? Some could certainly object that it's better to expose the basket as http://site.com/users/Louis/basket. The problem is then that I should deploy one web context for two applications (users & basket) while I want to be able to deploy the two services on two servers. To configure the ball, http://site.com/catalog/ball should expose links to colored balls. Let say Louis choosed http://site.com/catalog/ball?color=red. Now this resource would probably propose a link to the basket so we can post the configured product to it.
This is where I'm in trouble. For a basket, I admit it could be coupled with a product resource. But it's difficult for me to accept that the resource knows about the basket. Imagine that different kind of basket exists. Let say that the REST catalog is used by different shopping website. The product resource has no clue about its context! I feel this is correct while I'm then missing the REST 'transfer'. I guess the client application should know how to post the configured product URI to the current basket... except if I call the catalog passing a reference to the current basket: http://site.com/catalog/ball?color=red&basket=http://site.com/basket/Louis. Not too bad but I then cannot use caching for the catalog service anymore. GRRR... this is bad!
For now I pass the calculation of the transfer to the client application. It should just know how to interact with a basket resource.
Any idea about this is appreciated.
Joined: Dec 20, 2006
If your services talk only XML, i.e. return XML documents containing data, then the connection between catalog to basket is not necessary.
Such services are easy to implement, no connections are necessary between them and they are reusable from a third party app.
Now you only need GUI to use them. If you build GUI on the top of the same URLs then of course you will need to link from one to another. But your GUI may be a completely different URL where you simply use these 2 services. [ July 08, 2008: Message edited by: Vilmantas Baranauskas ]
Author of <a href="http://www.newsinjector.com" target="_blank" rel="nofollow">NewsInjector</a>