Gary is right. Developing an API is deceptively easy, but developing a useful API for a wide set of use cases in the real world, no so much. Some of the issues I've run into in a system that consumes 3rd party APIs (Fitbit, etc).
1) De-duplication. Sometimes you get push updates within a day that overlap earlier reports (e.g. an ever-growing summary of steps for the day on each sync). How about a historical re-download. Each service and data type often has different needs for de-duplication to ensure that time-series reads are accurate.
2) Reference times and time zones. Most DBs are geared towards timestamp storage, do you use a canonical time for a daily summary? What happens if the user changes timezones? Does your DB store midnight in current and travel timezones? What does that do for any reporting back? (Two summaries end up in one day). etc...
3) The canonical unit problem above is another fun one.
4) If creating your own data, separate "time of reference" and "time of entry". Entry is when I reported it, reference is what I reported about (only the same in devices and momentary assessment). Often the time of reference is a calendar concept, not an interval between two timestamps ("yesterday").
Some strategies I prefer when designing systems to consume 3rd party data:
- Store everything as you get it, make sense of it separately.
- De-duplicate on extraction; gain efficiency if needed via nightly archiving of redundant data.
- Represent assumptions about timezones when not specified by API
- Represent time explicitly. If you mean 'morning', then represent morning as a concept and don't rely on timestamps. Code can map the raw data into 'morning' which may be complicated, particularly with changing timezones.
- Be explicit about units; if you need a single-unit column (e.g. weight) for population queries or range queries, use a second internal canonical field that isn't exposed to the consumer of the API
- Don't be afraid to recompute values to send out via an API or rendered for the user, so long as you cache them and can prefetch the expensive stuff; better to have clean data than slightly more performant code!