A Comparison of Places APIs
Location Based Services are all the rage these days. The space is still being defined and the players are trying to differentiate their service offerings in order to attract the critical mass of developers. In this post I’ll draw a side-by-side comparison of the main features provided by the major Places API providers today. While I have no hard numbers to back-up the “major provider” claim, I’ll simply go for the web companies I would look for when building an application around Location services.
Here are my candidates ordered by their first API release date:
| Provider | Name | API Link | First Released |
| Yahoo | Yahoo GeoPlanet API | Yahoo! GeoPlanet™ | May 2009 |
| Foursquare | Foursquare API | Foursquare APIv2 | Nov. 2009 |
| Twitter Places API | Geo methods in Twitter API | Jun. 2010 | |
| Facebook Places API | Scattered under the Graph API | Aug. 2010 | |
| Google Places API | Google Places API | Nov. 2010 |
I won’t try to identify any “best” API in the end. This post is meant to allow the reader to make an informed decision on which API(s) to use.
Since there can be only one true collection of physical places (we’re not dealing with quantum realities fortunately) and lacking a common industry effort towards harmonization, the default behavior is to compete to win or dominate the space. One notable mention, Foursquare is now trying to aggregate the various place identifiers referring to the same physical place through Venues Project. Others will follow suit.
A comparison of features available in each API:
| Provider | Place Identifier | Place Data Structure | Checkin | Create Place | Geocoding |
| Yahoo | WOE ID | XML, JSON, GeoJSON | No | No | Yes |
| Foursquare | Venue ID | JSON, JSONP | Yes | Yes | No |
| Geo ID | JSON | No | No | Yes | |
| Numeric id | JSON | Yes | No | No | |
| Place id | JSON, XML | Yes | No | Yes |
| Provider | Nearby | Textual Search | Popular Places |
| Yahoo | Yes | Yes | No |
| Foursquare | Mandatory | Yes | Trending |
| Yes | No | Per topic | |
| Mandatory | Yes | No | |
| Mandatory | Yes | No |
| Provider | Place contents |
| Yahoo | Core only* |
| Foursquare | Contact info, specials here & nearby, who's here now, tips, photos, verified, who's mayor |
| Core only* | |
| Core only* | |
| Core, icon, rating, Google place details page URL |
What are the access restrictions when using the APIs?
| Provider | Authentication scheme | Terms of Use | Usage Limits |
| Yahoo | Open, requires appId | TOS | 50k queries/day |
| Foursquare | OAuth 2.0 | API Terms of Service | 200 requests/hour/method |
| OAuth | TOS | 350 requests/hour | |
| OAuth 2.0 | FB Platform Policy | N/A | |
| URL Signing | Acceptable use Requirements | Unspecified yet |
The only offering that felt “general purpose” was Yahoo’s. The API is designed to provide generic access to the place information while not tying to any specific Yahoo data. All of the other offerings are built around specific features provided by the vendor (although the core place information is neutral in each case).
An interesting comparison would be showing the POI coverage for each API provider but this data is unavailable.
I would have liked to add a few more comparisons like number of apps using each API, daily usage. This data is also not public (or at least I couldn’t find it).
Flickr image courtesy mil8