> Whereas when I fetch my todos I get the ID as something else:
> "assignee": {
> "id": *26385*,
> "name": "Arif Amirani",
> "type": "Person"
> },
> On login how do I get the todo user id?
Hi Arif -
This is, confusingly, exposing some of the internals of our data model.
There are actually three ids at play here: the Identity, the User, and the
Person.
The Identity is the id in your OAuth fetch. The User is a record that that
Identity is on this Account. And the Person is the actual Basecamp user.
That's the assignee id you listed.
So you can't directly correlate a Person id with an Identity id. However!
You can `GET /people/me.json` to get info about the currently authorized
Person and link that info to the Identity.
To make this a bit clearer, we've added identity_id to the Person JSON so
you can directly correlate Basecamp people with 37signals IDs.
Thanks for the update. The following may not be applicable to all but I feel the change is generic enough (maybe).
In my application, being on mobile, I would like to optimize on the number of HTTP calls that are made to fetch data. Given that an OAuth is mandatory, it should contain the "me" information in the response to make the "me" API call optional.
Thanks,
Arif CamperX - Basecamp Next for Android Team Envolto
> This is, confusingly, exposing some of the internals of our data model. > There are actually three ids at play here: the Identity, the User, and the > Person.
> The Identity is the id in your OAuth fetch. The User is a record that that > Identity is on this Account. And the Person is the actual Basecamp user. > That's the assignee id you listed.
> So you can't directly correlate a Person id with an Identity id. However! > You can `GET /people/me.json` to get info about the currently authorized > Person and link that info to the Identity.
> To make this a bit clearer, we've added identity_id to the Person JSON so > you can directly correlate Basecamp people with 37signals IDs.
On Fri, Oct 19, 2012 at 3:51 AM, Arif Amirani <arif.amir...@gmail.com>wrote:
> In my application, being on mobile, I would like to optimize on the number
> of HTTP calls that are made to fetch data. Given that an OAuth is
> mandatory, it should contain the "me" information in the response to make
> the "me" API call optional.
That would be convenient. However, the OAuth service is completely separate
from the applications it authorizes access to, so that information is not
available.
Making a "who am I?" request after you've authorized the app is a one-time
cost. I'd suggest focusing your HTTP optimization efforts on your main API
usage. Supporting HTTP cache freshness headers often has the biggest bang
for the buck: track ETags in API responses, make subsequent requests with
If-None-Match, and handle 304 Not Modified responses.
Interesting suggestions Jeremy. I never thought of utilizing them within an Android app as the APIs are completely stateless. I can imagine the benefits right away! Time to get hacking :)
On Friday, October 19, 2012 7:21:59 PM UTC+5:30, Jeremy Kemper wrote:
> On Fri, Oct 19, 2012 at 3:51 AM, Arif Amirani <arif.a...@gmail.com<javascript:> > > wrote:
>> In my application, being on mobile, I would like to optimize on the >> number of HTTP calls that are made to fetch data. Given that an OAuth is >> mandatory, it should contain the "me" information in the response to make >> the "me" API call optional.
> That would be convenient. However, the OAuth service is completely > separate from the applications it authorizes access to, so that information > is not available.
> Making a "who am I?" request after you've authorized the app is a > one-time cost. I'd suggest focusing your HTTP optimization efforts on your > main API usage. Supporting HTTP cache freshness headers often has the > biggest bang for the buck: track ETags in API responses, make subsequent > requests with If-None-Match, and handle 304 Not Modified responses.
