10-27-2014 09:17
10-27-2014 09:17
I am wondering why there is no API that can retrieve all information or a summary of the measurements that have changed since some arbitrary date.
Most of the time applications wants to keep information in sync so a very robust and alternative way for Fitbit Subscritptions would be to return measurements that have change since a point in time.
Assuming we have a nightly job that pulls information for a user. This process would basically need to ask Fibit: What information has been added or updated since yesterday?
This would simplify all existing implementations and would actually benefit the overall performance of Fitbit API since less traffic would be received.
What do you think?
Answered! Go to the Best Answer.
10-27-2014 15:01 - edited 10-27-2014 15:08
10-27-2014 15:01 - edited 10-27-2014 15:08
As long as your system is capable to handle all push notifications then you should be good.
On average we deliver very close to 100% push notifications to our API users.
99.8-99.9% to be exact. See http://status.fitbit.com for more details.
At this point we are not aware of any case that message was not delivered cause of Fitbit failure.
All the mesages that are not delivered are actually not delivered cause recipient is not able to get them.
That's being said if you app consumes 100% push notifications from Fitbit then it is guaranteed that yuo'll get every single push notification from us.
10-27-2014 14:29
10-27-2014 14:29
This is something that we've considered. The Subscriptions API tells you the user, the date, and the resource collection that has changed, so you only have to fetch the resources in the particular resource collection for the day.
10-27-2014 14:42
10-27-2014 14:42
The Fitbit Wiki recommends to implement both mechanisms (Subscription API and a Pull process) which can lead to problems if some Subscription API messages gets lost and never reaches that destination.
Having participated in a project that actually consumes your API, I would argue that a "What changed?" mechanism would have reduced significantly our development effort and also from a performance perspective it's a huge gain for both sides.
Having to implement the Subscription API and also having to implement a PULL process is a maintenance problem and also it leads to problems (blind spots) if Fitbit cannot guarantee that ALL Subscription API messages gets delivered correctly.
10-27-2014 15:01 - edited 10-27-2014 15:08
10-27-2014 15:01 - edited 10-27-2014 15:08
As long as your system is capable to handle all push notifications then you should be good.
On average we deliver very close to 100% push notifications to our API users.
99.8-99.9% to be exact. See http://status.fitbit.com for more details.
At this point we are not aware of any case that message was not delivered cause of Fitbit failure.
All the mesages that are not delivered are actually not delivered cause recipient is not able to get them.
That's being said if you app consumes 100% push notifications from Fitbit then it is guaranteed that yuo'll get every single push notification from us.