Hi Paul,
Thanks to both of you!
So, let me double check this. Based on what Christian quoted, I could have the session id in the URL (e.g.
http://host/{user}/info/{session_id}) and have the client remember this id during the session lifecycle.
Is that correct?
Thanks again,
-Sami
> Date: Fri, 11 Apr 2008 12:08:41 +0200> From: Paul.Sandoz@Sun.COM> To: users@jersey.dev.java.net> Subject: Re: Authetication + RESTful> > Hi Sami,> > Christian, thanks, i was going to do the same :-)> > For user specific information one can utilize user specific URIs i.e. > make the user information resource state and of course ensure that only > correctly authenticated clients have access to those resources.> > For example say you want a page that displays user specific information > and general information together. If the client goes to the general > information uri:> > http://host/info> > and the client is authenticated it could get redirected to:> > http://host/{user}/info> > otherwise the client gets the representation from the first URI. A user > who goes to "http://host/{user}/info" and is not authenticated could get > redirected to "http://host/info".> > One could also use a query parameter for the user and the approach would > still be valid.> > Does that help?> > Paul.> > Christian wrote:> > Hi Alireza,> > > > I don't think there is nothing wrong with using authentication in your > > rest service.> > Just take a look at a mail of Paul from yesterday :> > > > > > I know one of the key principles of REST is that your> > service should be stateless but its a fact of life that sometimes you> > have to store state.> > > > > > This is a common misconception :-) the stateless constraint is about > > *communication*, from Roy's thesis [1]:> > > > We next add a constraint to the client-server interaction:> > communication must be stateless in nature, as in the> > client-stateless-server (CSS) style of Section 3.4.3 (Figure 5-3),> > such that each request from client to server must contain all of the> > information necessary to understand the request, and cannot take> > advantage of any stored context on the server. Session state is> > therefore kept entirely on the client.> > > > ...> > > > Like most architectural choices, the stateless constraint reflects a> > design trade-off. The disadvantage is that it may decrease network> > performance by increasing the repetitive data (per-interaction> > overhead) sent in a series of requests, since that data cannot be left> > on the server in a shared context. In addition, placing the> > application state on the client-side reduces the server's control over> > consistent application behavior, since the application becomes> > dependent on the correct implementation of semantics across multiple> > client versions.> > > > I recommend reading section 4.5 of RESTful Web services book:> > > > Statelessness means that every HTTP request happens in complete> > isolation. When the client makes an HTTP request, it includes all> > information necessary for the server to fulfill that request. The> > server never relies on information from previous requests. If that> > information was important, the client would have sent it again in this> > request.> > > > More practically, consider statelessness in terms of addressability.> > Addressability says that every interesting piece of information the> > server can provide should be exposed as a resource, and given its own> > URI. Statelessness says that the possible states of the server are> > also resources, and should be given their own URIs. The client should> > not have to coax the server into a certain state to make it receptive> > to a certain request.> > > > > > > > > > 2008/4/10, Alireza Sami <sami2box@hotmail.com > > <mailto:sami2box@hotmail.com>>:> > > > Hi,> > > > I am a new member of this group. We are trying to develop a set> > of RESTful services for our application.> > > > In the definition of RESTful it is mentioned that RESTful is a> > protocol which is:> > > > - Client-server> > - *Stateless> > *- Cacheable> > - Layered> > > > Please correct me if I am wrong. My understanding is that, if I> > create a RESTful service, it should not return different results for> > different users because there is nothing like a Session object in> > the REST world.> > > > Now, if I support Authentication and/or Authorization for my> > service, I would have different results for different clients which> > is in fact against the fundamentals of this protocol. So, the> > question is that, how we should handle security without violating> > the essential rules of the REST?> > > > Your help is greatly appreciated.> > > > Thank you,> > -Sami> > > > > > ------------------------------------------------------------------------> > Get in touch in an instant. Get Windows Live Messenger now.> > <http://www.windowslive.com/messenger/overview.html?ocid=TXT_TAGLM_WL_Refresh_getintouch_042008>> > > > > > -- > | ? + ? = To question> ----------------\> Paul Sandoz> x38109> +33-4-76188109> > ---------------------------------------------------------------------> To unsubscribe, e-mail: users-unsubscribe@jersey.dev.java.net> For additional commands, e-mail: users-help@jersey.dev.java.net>
_________________________________________________________________
More immediate than e-mail? Get instant access with Windows Live Messenger.
http://www.windowslive.com/messenger/overview.html?ocid=TXT_TAGLM_WL_Refresh_instantaccess_042008