search

stefangrund / PersonalAPI

Personal API is a full featured RESTful API which collects your social media and quantified self data.
http://personalapi.org/
9 stars 1 forks source link

More Fitbit Data to Database #7

Open AndiH opened 10 years ago

AndiH commented 10 years ago

I'd like to save more information than only steps from Fitbit. I'm especially interested into floors.

But someone might also monitor their calories, their water intake, their […] with Fitbit. Why not save all the information the Fitbit API offers into the database? Is there anything speaking against that?

I would volunteer to edit the module accordingly.

It would have one major impact, though. The PAPI endpoint would need to change it's name from steps to something more general, e.g. fitbit. Is that alright?
Otherwise we'd need to split the Fitbit information up into individual tables / PAPI end points, like one for steps, one for floors, one for calories… I don't like that so much, since that creates the question, at which point the fragmentation stops. I'd rather sort it by service (hence fitbit).

What do you say?

AndiH commented 10 years ago

steps could be a meta-module, combining (in whatever way) different steps information from other modules.

With the new iPhone coming up I thought about testing the new coprocessor's step tracking ability. If that really is alright in quality, why not change from step tracking with Fitbit to some M8 iPhone step tracking…
Then, independently of the source (which would be /fitbit for Fitbit, and /stepTrackerapp for an API-enabled iPhone Step Tracker App), /steps would display the steps.

stefangrund commented 9 years ago

I really like the idea that there's one module for every data type, because that makes things a lot simpler to follow. But you're right, especially considering Apple's new Health app and it's variety of data types, that the "module per service” model would be far more practical.

This would require some changes to the table scheme, but should just work fine. We could also add a new level to the API to distinguish the different data types in a service's collection. The URIs could look like this:

/fitbit/→ all the Fitbit data, including steps, floor, calories etc. /fitbit/steps/ → all the steps from Fitbit /fitbit/123 → item 123 in the Fitbit collection

(/fitbit/steps/123 doesn't make sense if we save everything in one table.)

Then there could and should be a universal /steps/endpoint, which lists all the steps from different modules/services. I think we don't need a meta module, but some kind of registration so the PAPI knows about all the data types a module could use.

That said I would really appreciate if you could take care of the Fitbit module. What's your opinion?

AndiH commented 9 years ago

I really like your suggestion and think it's the right way to go! Both, the service-level for multi-data services, as well as universal endpoints (instead of meta-modules).

Introducing the new level to the PAPI would be far too much for my current knowledge, so it'd be great if you could take care of this?