foursquare2

foursquare2 copied to clipboard

This issue might be solely a lack of understanding on my part, but it seems like the search_venues method returns results that are divergent from Foursquare's current API docs and Try it Out results page.

These return a list of venues as the top level object in the response, but the gem returns a list of groups that appear to only ever have one object in it. That object then has an items array inside it which holds the individual venue objects.

I'm guessing this is expected behavior, because your tests align to it, but when I do a simple call to the same endpoint via curl it returns the documented format instead.

Am I missing something obvious, or is the gem using an old Venues API or something?

I confirmed this today by intercepting the raw response to this API call from inside the library and it has this in the meta section:

"errorType":"deprecated",
"errorDetail":"This endpoint will stop returning groups in the future. Please use a current version, see http://bit.ly/vywCav."

The changelog seems to indicate that this change happened on 6/15/11.

It would be nice to make these results consistent with the current version of the API. @mattmueller if you give me some guidance on how you generate your fixtures and where you'd prefer the v parameter be added to the requests, I'm happy to do the work.

Hey @jerodsanto - thanks for bringing this up. I haven't had time to dig in much but at first glance you definitely appear to be correct. For generating fixtures I usually just make a call using a tool like httpie (or even the browser) and then create the fixtures file from the response.

Having the v parameter set as part of the initialization of a Client instance would be great (so you define it along with the oauth token, etc.). Then this could just automatically be appended to all requests.

Hopefully this helps - anything you could contribute would be much appreciated!

@mattmueller the tricky thing about setting the v param is that we don't really know if the library as a whole can support any specific date, right?

Their versioning page says that if you don't specify a version then you get the oldest version of each endpoint. If we try to globally splat a v on all calls, how can we be sure that we can handle the version returned for all calls across the library?

The troublesome thing about this is that since we're always testing against fixtures, it might require that all fixtures be updated to return whatever the API returns for our given v. That seems like a lot of work.

An automated tool to generate all fixture files for a given version would help a lot, but that alone could be a decent chunk of work.

This is a particularly sticky situation, you're right. I'm going to mull on the appropriate way to handle this (even if it simply means drawing a line in the sand as to what is supported/tested) - any additional thoughts are welcome.

In the meantime feel free to update the venues endpoint to handle the newer version - I'm not sure how I'll handle the deprecation side of things here...will give it more thought this weekend when I have a good chunk of time to devote to this.

Any news? :+1:

I'd be happy to put some time in to this, if needed :+1:

Hey guys I'm short on free time at the moment - if any/all of you want to run with this it would be hugely appreciated...I think deprecating the handling of the old venues response format is probably sensible at this point and we can create a new major release letting people know it's a breaking change.