Re: Authorization and Statelessness

Eric,

Please could you start adding a tl;dr summary to the top of your posts

Cheers,
M


On Tue, Dec 11, 2012 at 7:24 AM, Eric J. Bowman <[email protected]>wrote:

> **
>
>
> Shea Levy wrote:
> >
> > What makes this different from, say, personalizing a response based
> > on the client's username?
> >
>
> There's nothing inherently unRESTful about personalization. Basing it
> on digest auth gives us caching advantages over both cookies, and tying
> it to /{username}/ URI allocation schemes. What we're after in REST is
> optimizing the hell out of GET, remember...
>
> Say I have a resource called "newsletter" I want all guests to be able
> to read, personalized for registered members using client-side XSLT to
> handle the mail-merge. The HTML representation of the newsletter must
> be the same for all users so we can set cache-control: public. It
> contains code which calls an XSLT transformation residing in an
> external .xsl file, whose URL must not vary for the sake of caching.
>
> But, that .xsl resource doesn't need to return the same representation
> for all users. The personal.xsl resource sets Vary: Authorization and
> has no 401 or 403 response. It has a 200 OK response which sets cache-
> control: public for unauthorized users, personalizing the newsletter for
> "Guest" (as opposed to, say, "Dave") which functions as a login link;
> whereas Dave would be linked to his control-panel UI. For example.
>
> Authenticated users GET a 303 redirection to the personal.xsl file in
> their user directory, which has cache-control: private set. Note that
> the personal.xsl files in this example apply to all newsletters, so
> it's useful to cache them. Note also that this is all invisible to the
> user, dereferencing the newsletter resource results in a personalized
> newsletter application steady-state -- which is a representation of the
> newsletter resource the user dereferenced.
>
> Actually, the HTML representation should be personalized for Guest by
> default, with the guest personal.xsl file containing an identity
> transform (does nothing). Also, the 303 redirects are cache-control:
> private.
>
> We can expand the example to only work this way for user-agents which
> Accept: application/xhtml+xml (which all do client-side XSLT 1 nowadays)
> while performing the XSLT transformation server-side and sending the
> personalized 200 OK response as text/html with cache-control: private
> for other user-agents (public, if not logged in). What this does is
> expand the set of representations such that each user now has two
> possible 200 OK responses, HTML and XHTML. Don't forget Vary: Accept.
>
> This isn't "the" RESTful way to do personalization, merely my attempt
> at a very simple example of basic mail-merge functionality in the REST
> idiom, to help answer your questions...
>
>
> >
> > Why doesn't authorization violate the statelessness constraint of
> > REST?
> >
>
> I'm going to turn that around on you, and ask what is it about my
> example you find stateful, specifically?
>
>
> >
> > It seems to reduce visibility (monitoring systems need to know
> > both the request datum AND the user's access rights to understand a
> > request)
> >
>
> Not really; intermediaries just need to know a user *has* access rights.
> As to visibility, if my example didn't have that property, it wouldn't
> have graceful degradation from highly-cacheable client-side merging
> down to cache-miss server-side merging.
>
>
> >
> > and scalability (server needs to store access-control metadata across
> > requests).
> >
>
> Sorry, not seeing it. The access-control metadata is part of the
> request, which leads to scalability. That a cookie is being used as
> access-control metadata is not apparent from such a request. It seems
> to me that the worst-case scenarios in my example, in terms of
> scalability vis-a-vis cache-hit ratio, are the best-case scenarios of
> non-RESTful approaches to personalization.
>
> IOW, that most requests cause processing on the server is what's
> expected with cookies, while REST gives me the means to avoid even
> contacting the server in many if not most cases, for the given example.
> The more millions of users, the greater the likelihood the newsletter's
> already cached closer to the user than the origin server, meaning
> server resource utilization per-user decreases as users increase, which
> is the real payoff to REST.
>
> -Eric
>
>  
>



-- 
Mike

http://twitter.com/mikekelly85
http://github.com/mikekelly
http://linkedin.com/in/mikekelly123