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 Twitter Places API Geo methods in Twitter API Jun. 2010
Facebook Facebook Places API Scattered under the Graph API Aug. 2010
Google Google Places API Google Places API Nov. 2010

The features of all these APIs are designed primarily to support (and promote) the business use cases of each respective competitor. One notable exception is Yahoo’s GeoPlanet API which advertises itself as being a general purpose API for referencing places.

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
Twitter Geo ID JSON No No Yes
Facebook Numeric id JSON Yes No No
Google Place id JSON, XML Yes No Yes

Discovering places is an important feature and all competitors offer it:

Provider Nearby Textual Search Popular Places
Yahoo Yes Yes No
Foursquare Mandatory Yes Trending
Twitter Yes No Per topic
Facebook Mandatory Yes No
Google Mandatory Yes No

What kind of data is returned when fetching a place?

Provider Place contents
Yahoo Core only*
Foursquare Contact info, specials here & nearby,
who’s here now, tips,
photos, verified, who’s mayor
Twitter Core only*
Facebook Core only*
Google Core, icon, rating,
Google place details page URL

*Core Place data is represented differently by each provider, see individual documentation for more details.

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
Twitter OAuth TOS 350 requests/hour
Facebook OAuth 2.0 FB Platform Policy N/A
Google URL Signing Acceptable use Requirements Unspecified yet

This concludes the comparison galore.

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