Open AndiH opened 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.
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?
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?
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 forfloors
, one forcalories
… 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 (hencefitbit
).What do you say?