On Apr 11, 2008, at 6:35 PM, Alireza Sami wrote:
> 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?
>
Yes, and when the client is finished with the session it could DELETE
it (or the session could just time out if it has not been used for a
while). This technique is commonly used for transactions, ticketing
or reliable POSTing scenarios.
I don't recall it being used for logging in type scenarios, i guess
it depends on what you want to do, but if you want to keep your URLs
permanent then using a session id could be problematic because such
URIs cannot necessarily be bookmarked, as by their nature such URLs
may be transitory. If you can avoid a session ID and instead rely on
HTTP authentication then user-based URLs can be reliably bookmarked
whether authenticated or not.
Paul.
>
> Thanks again,
> -Sami
>
>
>
> > Date: Fri, 11 Apr 2008 12:08:41 +0200
> > From: Paul.Sandoz_at_Sun.COM
> > To: users_at_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_at_hotmail.com
> > > <mailto:sami2box_at_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_at_jersey.dev.java.net
> > For additional commands, e-mail: users-help_at_jersey.dev.java.net
> >
>
>
> More immediate than e-mail? Get instant access with Windows Live
> Messenger.