isMayor with /users/self/venuehistory

[Matt Humphrey]

Hey,

Any reason/restriction why this wasn't included?

[Akshay Patil]

Because it's extra bits that we don't consider that useful for the vast majority of use cases.

~ak
--
Akshay Patil / Foursquare Platform Evangelist
@akdotcom / @foursquareapi

On Mon, Nov 7, 2011 at 7:11 PM, Matt Humphrey <pompe...@gmail.com> wrote:

Hey,

Any reason/restriction why this wasn't included?

--
To post to this group, send email to foursqu...@googlegroups.com
 
http://groups.google.com/group/foursquare-api

[the Guru]

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 ;)

[Akshay Patil]

It's certainly useful in certain situations, but not in all, and full venue objects can be very large -- that's why we decided to put the most important details in a compact representation.

You can reduce the number of API requests you make by caching venue details on your server.

~ak
--
Akshay Patil / Foursquare Platform Evangelist
@akdotcom / @foursquareapi

[the Guru]

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?

[Akshay Patil]

We've had a couple of discussions about offering different levels of detail to endpoints, but haven't had a compelling reason to de-prioritize the other things we're working on in order to really dig into it. You'd probably greatly enjoy http://engineering.foursquare.com/2011/07/08/apiv2-woulda-coulda-shoulda/, in particular the "Object consistency and level of detail" is a summary of the issue at hand.

You can cache venue details for up to 30 days before refreshing. Also... why are retrieving a user's entire venuehistory every 15 minutes? that's.... bananas.

Be sure to read https://foursquare.com/legal/api/platformpolicy -- it spells out the caching time limits for various types of data.

~ak
--
Akshay Patil / Foursquare Platform Evangelist
@akdotcom / @foursquareapi

[the Guru]

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?

[Akshay Patil]

You should use the User Push API + cache state on your server: https://developer.foursquare.com/docs/realtime.html

As for the other stats (number of friends with, people there) you'd be best of making a lazy request to the server (upon plug-in view) and caching for 15/30 minutes. That way you're maxed out at making 2-4 requests / plug-in user, which scales nicely, even if gain millions of users or have millions of widget views.

~ak
--
Akshay Patil / Foursquare Platform Evangelist
@akdotcom / @foursquareapi