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 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. -- James Manger _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
