isMayor with /users/self/venuehistory

Showing 1-8 of 8 messages
isMayor with /users/self/venuehistory Matt Humphrey 11/7/11 4:11 PM
Hey,

Any reason/restriction why this wasn't included?
This message has been hidden because it was flagged for abuse.
Re: isMayor with /users/self/venuehistory the Guru 11/9/11 3:20 AM
I'd consider it useful. It would also be useful to include the full venue data for each endpoint that contains a venue. That would actually save a great deal of API calls.

For example ...

If I want to display my venue history instead of making just 1 API call to users/self/venuehistory I have to make that 1 plus 250 additional calls to each venues/*** in order to get full data.

Please ;)
This message has been hidden because it was flagged for abuse.
Re: isMayor with /users/self/venuehistory the Guru 11/9/11 5:01 PM
Completely understand the size issue Akshay, so how about a compromise :)

Would it be possible to add a parameter to endpoints that return the venue subset which would allow us to receive the full venue data-set
eg fullVenue=true (which of course would default to false meaning those not specifically requesting it would continue to receive the reduced data-set)

Also, I do currently cache data in order to reduce API calls but consider this ...
venuehistory returns a maximum of 250 venues ... 1 API call
each of those venues needs to be called ... 250 API calls
if we cache for 15 minutes then every hour we would need 251 * 4 API calls ... or 1004 API calls :(

Isn't our hourly limit 500?
This message has been hidden because it was flagged for abuse.
Re: isMayor with /users/self/venuehistory the Guru 11/10/11 6:05 PM
Maybe if I give you the context of my application it might make things a little clearer.

I wrote a wordpress plugin which initially utilized the API to retrieve recent checkins which allowed a blog owner to display where they had been on their blogs. So for starters, the application is only retrieving information belonging to the specific blog owner.

So this API call is actually initiated not by the blog owner but by a visitor to site, which led me to including caching capabilities. It is pointless having 100 visitors come to your blog in the same minute and initiate 100 API calls and so I added an option to cache the data and only call the API when the cache expires.

Next question ... how long do we keep the cache for? I had to snicker at your 'bananas' comment. Consider this ...

Lets say I checkin to the zoo. When will my website actually show I have checked in there? Well that depends on the cache expiry. If I expire my cached data every 15minutes then my website will be uptodate in a maximum of 15minutes. But if I don't expire my cache for 24hours then it will take that long for my site to be correct. (and remember that we live in a NOW society)

So how does this relate to venue data? Well with the current venue data provided as part of another endpoint, I can display basic stats about the venue ... # of tips, # of people who have checked in, total # of checkins.
But with the full venue data I could also display things like how meny people are here now, or how meny of my friends are here with me, or who the current mayor is, etc

Again, caching becomes a big part of this information. If I cached every 24hours and I was the first to the zoo, my site could say that I was 'at the Zoo with no fiends' ... pretty sad really and it could stay that way for up to 24 hours. But if I refreashed the cache after 5 minutes it could say I was 'at the Zoo with 15 friends' because that is what is happening now.

Now I know I have been talking about recent checkins, but checkin history is the same principle. It would be great for me to be able to display information such as -

I've been to Zoo. The last time I went there was on xxx. Currently there are 150 people checked in here and the mayor is xxx. Check out these tips ...

Currently I cant do that unless I API the venue individually, and there could be up to 500 venues, all needing to be updated (assuming the blog is getting visitors of course) every 15minutes to keep the data current.

Make sense?
This message has been hidden because it was flagged for abuse.