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

17739Re: [rest-discuss] User dependent Resources

Expand Messages
  • Craig McClanahan
    Sep 6, 2011
      On Tue, Sep 6, 2011 at 6:35 AM, Jim Purbrick <jimpurbrick@...> wrote:
       

      We're hoping to solve this bootstrapping problem by returning initial URIs for "my stuff" during authentication.


      So, you get "authenticated-as": "http://someservice.com/users/42/" back when authenticating and then the "/users/42/" resource is just a normal RESTful resource connected to everything else it's related to via hyperlinks.

      Hopefully this will be the only place in the API where responses vary based on who's asking and everything else will be a web of RESTful resources that are the same regardless of who's asking and so highly cachable.

      Cheers,

      Jim


      Authorization and resource discovery are two separate concerns.

      Because REST interactions are supposed to be stateless, you'll need a mechanism that validates every request, not just the "first" one.  Lots of services I've seen use HTTP Basic for that (and run across SSL to avoid the password being visible to snoopers).  Other options include an API key that has to be included in every request (although this is often used just to grant permission to use the service, not identify a particular user), or more involved authentication strategies like OpenID or OAuth.  You use OAuth, for example, to interact with APIs to Facebook, SalesForce.Com, and LinkedIn.

      Your "return the http://someservice.com/users/42 resource" would be the right answer if the caller requested that URI, but not if they requested, say "http://somservice.com/customers/123".  In the latter case, they should get what they asked for (if authorized and allowed to see it), a 403 (if authorized and not allowed to see it), or a 401 (if not authorized).

      A strategy I like for resource discovery is to have the very top resource in the URI space (http://someservice.com/") serve that purpose.  I have found this to be the simplest to explain to potential client developers, and it makes intuitive sense that this is the "front door" (so to speak) to the entire service.  SalesForce in particular employs a variant of this strategy that is also helpful for long term use -- part of their discovery resource is the supported versions of the API itself (with possibly different URIs for each), so a client can program against a particular version of the API without knowing ahead of time what the version's base URI will be, but knowing that they can find this out from the discovery resource (and cache it for some reasonable amount of time).

      Craig McClanahan

    • Show all 3 messages in this topic