Active.com Developer Blog

We recently enabled a feature that allows you, as a developer, to understand how your calls to the Active.com API are performing.  Check out the screencast below:

Update: We've worked busily to diagnose this issue, applied a couple of patches, and believe we've solved the timeout problem.  If you're still receiving 503 errors shoot me an email (jeremy dot thomas at active dot com) or reply to this post.

Yesterday we had a few issues with our Search infrastructure that caused intermittent 503 (Gateway timeout) errors with our Active.com Search API.  We worked busily to resolve the issue and thing are looking much better today.  But we're not out of the woods as we're still gathering data to fully understand root cause, although we can say it doesn't appear to be volume-related.  As such, you may experience sporatic 503 errors today. 

I've been working behind the scenes to overhaul our API documentation in order to make it more user-friendly.  Our old layout didn't do a great job of showing how the APIs work together.  So I've changed that.  The Active.com API page has been updated to show how the Details, Search and Reviews API work together.  Each API was also given its own page that breaks into usage details.

We've also deprecated the Asset Syndication API in favor of the Search API.  Developers can no longer sign up for the Asset Syndication API.  Existing users of said API will continue to see uninterrupted service.  But they are strongly encouraged to switch.

Finally, we've added a new Camping API!  Reserve America, which is part of The Active Network, contains campground data for 97% of the US and Canada's national and state/provincial parks.  Today we are releasing the Active.com Camping API, backed by Reserve America's database, so that developers can tap into this rich information source.  The API can be used to find all campgrounds in California that allow RVs, pets, have a golf course and are available on 15 September, 2010 for 8 days.  Or it can be used to find campgrounds in Colorado that reside along rivers or lakes.  Or it can be used to get a rich description of a campground including driving directions, recommendations and ammenities (these descriptions are often authored by park rangers).

Check out the API documentation at http://developer.active.com/docs/Activecom_Camping_API.  We're excited to see the types of applications that will be developed with this rich data set.

I'm proud to annouce the release of the Active.com Reviews API.  With it, a developer can query all of the reviews for a particular event, like the 2010 La Jolla Half Marathon, http://apij.active.com/rest-service-reviews-1.0/reviews/asset/3a1b52e7-9d67-42f2-9bb8-f4c624a0d280.  The API returns the:

• average rating (0 to 5),
• number of reviews (reviews are free-form text, similar to comments)
• number of ratings (ratings are a score of 0 - 5)
• individual reviews
• individual ratings
• review dates
• reviewer's userId
• reviewer's avatar

Complete documentation for this API is located at http://developer.active.com/docs#reviews.

Today we have officially deprecated the Asset Syndication API and would like developers to use the Search API instead.  The Asset Syndication API was our first public API and was successfully integrated to by many developers and business partners.  We will continue to support those who have already integrated to the Asset Syndication API.  But we will no longer allow developers to sign up for access to it.

The Search API is far more robust and has an entirely new technology set behind it (although it serves the same data).  It has excellent support for metadata-based queries as well as free-form, keyword-based searches.  If you have any questions, please comment on this blog or hit me up on twitter @jgrahamthomas.

One of the Search API users noticed an issue with our Geo Data the other week, and we stopped to investigate what was going on.  As you can see through the Mashup he's developing, http://dave.tycho.ws/ActiveMap/?loc=mi&racetype=running, running events that are supposed to show up in Michigan are actually appearing in Texas.  We had a few issues with our Geocoding service provider last month whereby an interface update they rolled out produced inaccurate results in some cases.  We worked with them to try and resolve the issue, but were unable to reach common ground.  So we ended up switching Geocosing service providers and have seen our accuracy improve significantly.

The unfortunate byproduct of this is some of the events entered into our system last month have bad Geodata, and after analysis the cost to fix those records isn't worth the benefit.  So here's what you can do if you find inconsistencies:

• Include the city/state combination along with your keyword in the search request, ane leave "l=everywhere".  Here's a sample query for running events in San Diego, CA, for example, http://api.amp.active.com/search?k=running+san+diego+california&f=activities&v=xml&l=everywhere&r=50&s=relevance&m=meta%3AstartDate%3Adaterange%3Atoday..&api_key=wuhmn9ye94xn3xnteudxsavw.
• Include only the state in the "l" field, i.e. "l=California".  This does a string match in our system and bypasses the lat/long data that we're having some inconsistencies with.  Here's an example search for running events in California http://api.amp.active.com/search?k=running&f=activities&v=xml&l=California%2C+US&r=50&s=relevance&m=meta%3AstartDate%3Adaterange%3Atoday..&api_key=wuhmn9ye94xn3xnteudxsavw.

We fully expect that over the next 2 months our inaccurate records will reduce significantly as events either occur or are updated by event directors in our system.

Regards,

Jeremy

Yesterday we rolled out an update to the Search API that contains two significant improvements.

Improvement 1

Duplicate data has been removed.  Previously, some records contained multiple occurences of elements such as "assetId" or "eventId".  These elements will now occur only once.

Improvement 2

We are now consistent with the way in which collections are represented.  Previously, a collection with more than one value, such as the "tag" collection, would have been represented as:

<tag>
<value>event:10</value>
<value>Running:10</value>
</tag>

But a collection with one value was represented as:

<tag>Running:10</tag>

We've since updated the API to be consistent, so that collections with one value have the same format as those with multiple values.  So now, for example, the "tag" collection with one value appears as:

<tag>
<value>Running:10</value>
</tag>

We've been working to deprecate the Asset Syndication API in favor of the more robust, scalable Search API.  Included in this effort is changing the contract behind the Asset Syndication Widget.  We'll be making changes today and tomorrow.  Look for updated documentation soon.

JT

cross-posted from the Active.com Product Developer blog

I'm happy to announce that I'll be speaking at the Business of APIs Conference in New York City on Monday, 16 November, 2009. We've been steadily investing in our public API over the past few months with the Search API being the most recent addition to our portfolio. I'm going to be telling the "Active Story", starting from the origins of our company and how we grew through acquisitions. The prime directive of active.com was to become the world's most comprehensive directory for things to do, and in order to accomplish this we needed to ingest data produced by the products we'd acquired in order to make them discoverable on the site. An internal initiative, then, drove us to consider interoperable APIs as a means to facilitate integration between systems we owned, and at that APIs that could be accessed across data centers. As a by product of this initiative we found that external developers were interested in our data, hence the birth of developer.active.com.

Anyway, it's an interesting story, and if you're NYC and want to hear the details, sign up for the Business of APIs Conference and come on down to Sunwest Studios.