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