Tag Archives: API
At last month’s QS Europe 2013 conference, developers gathered at a breakout session to compile a list of common obstacles encountered when using the APIs of popular, QS-related services. We hope that this list of obstacles will be useful to toolmakers who have developed APIs for their tools or are planning to provide such APIs.
- No API, or incomplete APIs that exposes only aggregate data, and not the actual data that was recorded.
- Custom authentication mechanisms (instead of e.g. OAuth), or custom extensions (e.g. for refreshing tokens with OAuth 1.0a).
- OAuth tokens that expire.
- Timestamps that lack time zone offsets: Some applications need to know how much time has elapsed between two data points (not possible if all times are local), or what e.g. the hour of the day was (not possible if all times are converted to UTC).
- Can’t retrieve data points going back more than a few days or weeks, because at least one separate request has to be made for each day, instead of being able to use a begin/end timestamp and offset/limit parameters.
- Numbers that don’t retain their precision (1 != 1.0 != 1.00), or are changed due to unit conversion (71kg = 156.528lbs = 70.9999kg?).
- No SSL, or SSL with a certificate that is not widely supported.
- Data that lacks unique identifies (for track-ability, or doesn’t include its provenance (if obtained from another service).
- No sandbox with test data for APIs that expose data from hardware devices.
- No dedicated channel for advance notifications of API changes.
This list is by no means complete, but rather a starting point that we hope will kick off a discussion around best practices.
If you’re like me, then you’re always looking for new ways to learn about yourself through the data you collect. As a long time Fitbit user I’m always drawn back to my data in order to understand my own physical activity patterns. Last year we showed you how to access your Fitbit data in a Google spreadsheet. This was by far the easiest method for people who want to use the Fitbit API, but don’t have the programming skills to write their own code. As luck would have it one of our very own QS Meetup Organizers, Mark Leavitt from QS Portland, decided to make some modifications to that script to make it even easier to get your data. In this video below I walk you through the steps necessary to setup your very own Fitbit data Google spreadsheet.
Step-by-step instructions after the jump. Continue reading
In this talk, Beau Gunderson shares a way to bring all of your disparate data sets, from Facebook to Twitter to Foursquare to Zeo to Fitbit to Runkeeper, together in one collection to be accessed through simple APIs. It’s part of an open source development effort called The Locker Project. The hope is to be able to see new patterns and correlations by bringing these sources of data together. Beau learned some interesting things about himself, and had fun playing with different questions he had about his data. (Filmed by the Seattle QS Show&Tell meetup group.)