On Thu, May 13, 2010 at 4:54 PM, Manger, James H < james.h.man...@team.telstra.com> wrote:
> Evan, > > > we have no API endpoints that are only arrived at by links > > This doesn't sound very web-friendly. Your APIs don't have to follow a > web-style, but an IETF spec should support web-style APIs. I didn't say that our endpoints can't be arrived at by links. I said our APIs all can be called directly and clients need to know how to call them directly. Clients need to have a way of finding out: 1. The available endpoint URLs, and 2. The scopes to ask for to access these URLs "sites" by itself is insufficient to be useful to our developers. > I am a bit surprised with your statement as a whole lot of Google APIs do > have API endpoints arrived at by links. I thought most Google Data APIs > followed the Atom Publishing Protocol. This uses links extensively. For > instance, <link rel="edit" href="..."/> tells the client the API endpoint to > at which an entry can be updated. > > There are lots and lots of <link rel="..." href="..."/> relations defined: > in the Atom spec, in the APP spec, in GData docs (not specific to particular > APIs) etc. > > Definitions of none of these link relations state that they MUST or MUST > NOT be part of the same API. > > > > > Another note: Where do we anticipate clients storing the sites parameter > in the User-Agent flow? Right now the access token can be set as an HTTP > cookie by the client. Do we expect them to set a separate "sites" cookie and > respect this on their server when making requests? This seems complicated. > > Presumably the client needs to store the access token, the expiry date, > perhaps the scopes etc. Easy solution: store the base64-encoding of the JSON > representation of the token details. > Currently the client side flow is really simple: 1. Set access token as a cookie, with 2. An expiration matching the expires_in time Are you suggesting the client parse the URL parameters, create a JSON block, base64 encode the block, and then write an HTTP cookie? > > -- > James Manger > >
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
