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