Understanding REST in terms of scalability, performance,

up vote1down votefavorite 1

I just want to know if my thoughts concerning REST are right. Let's imagine we have a shopping site. With a conventional approach the shopping cart would be stored in the users session so that the server has to manage many items for user( User#1: item1, item2, item3; User#2: itemA,itemB, item3,...). So the server has to have lots of memory/computing power if there are more than thousand users browsing on the site and adding items to their shopping cart. In a REST approach there is no session, so the client has all information about the items in the shopping cart. This means that the server doesn't need to have such big memory requirements and i can easily scale this. Now if I add an item in the non-REST-approach to the shopping cart it would it would go directly in the session. If I add an item in the REST-approach I have to update the entity in the database (/shoppingcart/1234/) and this would take a bit longer since I have to go one level deeper (client->server->database). Is this correct so far or am I missing or misunderstanding a point? performance rest scalability share|improve this question edited Jul 19 '11 at 20:25 Darrel Miller 47.3k863115 asked Jul 13 '11 at 11:06 QuestionGuy7 293

REST doesn't care whether the shopping cart is on the client-side or the server-side. REST is, in your case, about how resources on the web, and operations on them, are exposed to clients. –  bzlm Jul 13 '11 at 11:14 ok, i've understood this point with GET,POST,PUT,DELETE. But if i decide to manage my shopping cart not on the client than it would be slower with REST since i can only store them in the database and not in a session of the server? –  QuestionGuy7 Jul 13 '11 at 11:20 that doesn't have anything to do with REST. You're conflating REST with a few other concepts (cf. this answer).–  bzlm Jul 13 '11 at 11:21 @bzlm, the link is not pointing to either of the answers. –  Reddy Jul 13 '11 at 15:18 add comment

2 Answers

activeoldestvotes

up vote4down vote

In a REST approach there is no session, so the client has all information about the items in the shopping cart. The REST statelessness constraint doesn't imply that the client needs to keep track of all information about the items in the shopping cart (please don't do that). But it does mean that the state of the shopping cart is addressable (that the client has all the information needed to service the request). Consider the following URL: /shopping-cart/john.howes My understanding of the statelessness constraint is that if I or you or anyone navigates to that link, we will get some representation of the same resource (assuming we have the authorization to view it). It may be XML or JSON or HTML, and it may be in English or French, but the underlying resource is the same. And if I bookmark that URL and view it later on another device or email it to a friend, we would get the same resource (assuming it still exists and we have authorization to view it). So, because I had a link to /shopping-cart/john.howes, I had all the information needed to service the request. Now if I add an item in the non-REST-approach to the shopping cart it would it would go directly in the session. If I add an item in the REST-approach I have to update the entity in the database (/shoppingcart/1234/) and this would take a bit longer since I have to go one level deeper (client->server->database). I think, whether you're using REST or not, adding large objects to session state is a recipe for disaster (for maintainability, scalability, and sanity). So, I'd bite the bullet and use a database. And I think you're essentially right: REST doesn't say much about how data is stored on the server, but it does imply that you don't store the current state of a user's session in memory on your web server. I think you have lots of options for optimizing for performance. Keeping everything in session is not a very good option. I hope this helps. John share|improve this answer answered Jul 13 '11 at 12:48 John Howes 21615

Have you heard about RESTFest? restfest.org It would be great to have you join us. –  Darrel Miller Jul 13 '11 at 20:47 Not a chat, @Darrel. :) –  bzlm Jul 14 '11 at 8:54 Don't want to continue the chat, @bzlm, so I responded via twitter. :) –  John Howes Jul 14 '11 at 11:55 add comment

up vote1down vote

There are two distinct ways of doing a shopping cart in REST. One is where you actually make the shopping cart a resource and assign it a URI, as you describe. The other is where the contents of the shopping cart are kept on the client right up until the point where the user places the order. There are pros and cons to both approaches and yes, storing the shopping cart as a resource will require storing the shopping cart in a database (it could be a in memory database though!). However, I don't think trying to do a perf comparison on this aspect, between using sessions and storing carts as resources, is particularly valuable. share|improve this answer answered Jul 13 '11 at 12:29 Darrel Miller 47.3k863115

add comment