Deep, I haven't tried building a RESTful e-commerce site and I'm not sure I would but...
REST says state should be maintained on the client side so if you were going to build a RESTful e-commerce site you'd have to keep the cart on the client side. Storing it in a cookie would maintain state across application usage. HTML5 is supposed to offer more possibilities for local storage. You're right that once your servers are storing session state you're not RESTful so you're left with HTTP authentication which can be problematic (see http://www.artima.com/weblogs/viewpost.jsp?thread=155252) or using a stateful session server in your environment and filtering (Restlet filters include an Authenticator and an Authorizer) all your calls by checking the cookie, or some custom Auth header, or a query param, or whatever against the stateful session server. OpenAM is one such session server (http://forgerock.com/openam.html). This approach benefits from some of the advantages of REST in that you shake loose some of the scalability problems doing it this way. For example you can now load balance two servers with the exact same services on each of them (api1.example.com and api2.example.com) and they don't have to know about each other since they each check in with the session server to authenticate a user. But of course your session server is by no means RESTful and now you may be forced to beef it up for high-availability and build in failover since everything goes through it now and you can't avoid having it fail. Bottom line, either you use HTTP authentication or you resign yourself that something in your environment has to be UnRESTful. HTH. On 10/10/11 5:47 AM, "D G" <[email protected]> wrote: >Hello all RESTlet experts, > >I am new to RESTful web services and RESTlet. WE only have experience >building servlet based web applications (Servlet/JSP on JBoss/Apache). >Now, >we are building a RESTlet based application where the server side API >would >be used by two types of clients - web using browser and swing based via >desktop. > >What I understand is that as per REST concepts a) server can not maintain >sessions to improve scalability and few other reasons b) each request from >client should be self-contained > >Now, I am really confused how to achieve this. Suppose we take a simple >shopping cart application. > >Step 1) Client sends the authentication request, server authenticates and >server responds OK. > >Step 2) Client sends a request to add an item to the shopping cart. Server >responds OK. > >Step 3) Client sends another request to add 2nd item to the shopping card. >Server responds OK. > >Normally, in a normally web app, a session is created in Step 1 on server >and from that point onwards all the requests pertaining to that client are >automatically associated with the same session and we store session state >(Shopping Cart in this case) in the session object and retrieve/update it >with subsequent requests from the client. > >Now, in the above scenario: > >1) how do we authenticate and authorize Client in Step 2 and 3 if there is >no session maintained on the server ? > >2) does client need to send some additional information with each request >? > >3) How do we retrieve the client specific Shopping Cart in Step 3 ? > >4) Does the client need to send it's Shopping Cart that was >created/returned >by server in Step 2 again in Step 3 ? > >Obviously, this is the simplest use case and so every one developing >RESTful >web services must be designing their app to handle this. What is the best >and most common way to handle session management, authentication, >authorization in RESTful web services using RESTLet ? If we have to >maintain >cache on server side with the client's data then how is this different >from >server maintaining sessions on our behalf ? > >Thanks in advance, Deep > > >-- >View this message in context: >http://restlet-discuss.1400322.n2.nabble.com/Sessions-in-web-applications- >using-RESTlet-tp6876478p6876478.html >Sent from the Restlet Discuss mailing list archive at Nabble.com. > >------------------------------------------------------ >http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=285 >2570 This message and any included attachments are intended only for the addressee. The information contained in this message is confidential and may constitute proprietary or non-public information under international, federal, or state laws. Unauthorized forwarding, printing, copying, distribution, or use of such information is strictly prohibited and may be unlawful. If you are not the addressee, please promptly delete this message and notify the sender of the delivery error by e-mail. ------------------------------------------------------ http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2852619
