Loading ...
Sorry, an error occurred while loading the content.

Re: [rest-discuss] Authorization and Statelessness

Expand Messages
  • Mike Kelly
    Eric, Please could you start adding a tl;dr summary to the top of your posts Cheers, M ... -- Mike http://twitter.com/mikekelly85 http://github.com/mikekelly
    Message 1 of 4 , Dec 11, 2012

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


      On Tue, Dec 11, 2012 at 7:24 AM, Eric J. Bowman <eric@...> 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:

      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.



    Your message has been successfully submitted and would be delivered to recipients shortly.