Calling WebAPI and assuming that response will always be same format

[MunkiiYebee]

We call a number of the Web Api endpoints and our code is assuming that the response will always be JSON that is serialisable into a very specfic format.

99.9% of the time that is correct, for example, calls to the"Get Activity Tracker Resource by Date Range Time Series" api endpoint below get us an array of  Date and Calories.

https://api.fitbit.com/1/user/-/activities/tracker/calories/date/{0}/{1}.json?CacheBuster={2}

However sometimes the deserialisation of the JSON response fails and our app is not handling that well at all. I assume that sometimes the response from that endpoint could be a completely different JSON format such as if there is an issue with the user's data or acccount.

Where is the documentation for the different response formats?

Thanks

[Gordon-C]

Hi @MunkiiYebee 

The documentation for the endpoint that you're calling is https://dev.fitbit.com/build/reference/web-api/activity-timeseries/get-activity-timeseries-by-date-r....   We provide a sample response on the page.   

May I ask where did you get information that we support the query parameter "CacheBuster"?  I'm not aware that we support that query parameter.

Gordon

[MunkiiYebee]

Thanks @Gordon-C .

I know about the success response and that's what we are expecting when the requests succeeds. What I don't iknow is what for the body will be when it is not a HTTP 200 success.

Do you have an error message format?

May I ask where did you get information that we support the query parameter "CacheBuster"?  I'm not aware that we support that query parameter.

This coding was done before I was on the project. Maybe it is to bust some client side cache in our libraries

Thanks

[Gordon-C]

See if https://dev.fitbit.com/build/reference/web-api/troubleshooting-guide/error-handling/ gives you the information you need.    I would remove the CacheBuster parameters.   It could be causing issues on our side.

[MunkiiYebee]

Thanks Gordon.


Sent from Outlook