[andrewpbrett]

One design dilemma we ran into when building this out is the "username" endpoint. When a user grants access, the OAuth default is to just pass the token back to the client. But to access other endpoints, the client needs to know the username of the user that just granted access.

So we added the "username" endpoint, but weren't (and still aren't) quite satisfied with that as a solution. Have other API designers run into this same issue? Seems pretty common - would like to hear what HN has to say about it.

[klochner]

Facebook uses a reserved "me" parameter which always refers to the user who authorized the token. For example:

https://graph.facebook.com/me/friends?access_token=TOKEN

[jmillikin]

My preferred ways to solve the problem:

1. Make the OAuth server end append additional parameters to the successful-auth URL. It would end up looking like http:// some-app.com/oauth-ok?access_token=abc123&username=jdoe

2. Provide an endpoint with the same data as /user/<name>.json, but without the uesrname in the URL. OAuth clients would query this new endpoint instead. While you're at it, might as well allow the client to request the goal list at the same time. Ideally, a client should only have to send a single request to populate its "home page".

[dreeves]

Thanks, klochner and jmillikin, for setting us straight on this!

We're taking both your suggestions: username is returned along with the token as part of the oauthing, and also you can just use "me" in place of the username for any endpoint, and it's essentially macro-expanded.

No more lame-o dummy resource just for getting the username! (Well we're leaving it there in case anyone has already written code that uses it but it can now be undocumented.)

Thanks again for the help!