fitnessActivities requires an id, and other API thoughts #2
Description
Thanks for the library, and the recent changes to make it so that the access_token is easier to set per request.
After the recent changes to API permissions (so that developers can now access their own data), I started a new app that requests runkeeper.fitnessActivityFeed(access_token,callback,function(data){...}) and then loops over the returned data.items and loads that item's uri. At the moment I can't use your runkeeper.fitnessActivities(...) method because each item provides its own uri - I assume that method is just a stub and you haven't got to it yet?
Given the fact that RunKeeper's API provides uris dynamically for each resource, it might be more appropriate to provide a general purpose get method that accepts a (relative) uri, a media_type and an access_token. Something like:
HealthGraph.prototype.get = function(uri, media_type, access_token, callback) {
console.log("This method is -- " + uri);
var request_details = {
method: 'GET',
headers: {
'Accept': media_type,
'Authorization': 'Bearer ' + access_token
},
uri: "https://" + this.api_domain + uri
};
console.log(request_details);
request(request_details, function(error, response, body) {
console.log(request_details.method + " " + request_details.uri);
console.log("ERROR");
console.log(error);
console.log("RESPONSE");
console.log(response);
console.log("BODY");
console.log(body);
if (error) {
callback(error);
}
else {
callback(null, body);
}
});
};For me, this method can be used to call /fitnessActivities (the uri given by /users for accessing fitness_activities) with media_type application/vnd.com.runkeeper.FitnessActivityFeed+json and then loop over each item and call the method again with the given uri and media_type as application/vnd.com.runkeeper.FitnessActivity+json.
...
To initialize the API, instead of loading your api.json file you'd do a call to /user with media_type application/vnd.com.runkeeper.User+json and then discover all the other endpoints. The docs indicate that the authors intend the /user endpoint to be the only one hard-coded in your application. It's a little strange to me to "discover" endpoints but hard-code media types, but I think that's OK :)
Note I've also modified callback to receive an error as the first argument, as is common in node.js libraries of this kind.
Anyway, let me know what you think. I'm happy to implement this and push it up to my fork if you'd like to take a look before committing to it.