users@jersey.java.net

Re: Authetication + RESTful

From: Christian <christian.rivasseau_at_gmail.com>
Date: Fri, 11 Apr 2008 10:49:19 +0200

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>:
>
> 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>
>