Re: Authorization and Statelessness

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