This appears to be the Garmin API, which supports OAuth1a, has no public documentation, and the limitations are pretty well detailed as well on the company blog of the author:<a href="https://blog.smashrun.com/2021/05/21/a-new-garmin-api/" rel="nofollow">https://blog.smashrun.com/2021/05/21/a-new-garmin-api/</a>.<p>What an awful experience, I hope I never have to use it.
A couple of things I omitted for brevity:<p>The async server response doesn't contain the data. It contains a <i>link</i> to retrieve the data. So make a request and then wait to for a link to be sent to your server that you can use to retrieve the data for a limited time.<p>The responses sent to the server don't correspond one to one to the requests. One response may contain data for many requests, and many responses may contain data for one request. Each response contains data for many UATs.
I’m a bit confused as to why a “unit test” would ever be hitting a real, external API. I would call that an integration test, E2E test, etc. that probably shouldn’t be run frequently (as part of a normal build, for example).<p>This API sounds like garbage, don’t get me wrong; and because of that, mocking it’s behavior is going to be almost impossible.
On the same topic: API Practices If You Hate Your Customers <a href="https://queue.acm.org/detail.cfm?id=3375635" rel="nofollow">https://queue.acm.org/detail.cfm?id=3375635</a>
It sounds pretty malevolent to me.<p>But I'm disinclined to attribute malevolence to people without a motive. So I'm inclined to think they had to implement an API for some contractual reason; they put their best architect on it, with a brief to minimise server load at all costs; he then handed it off to the most junior developer team.<p>BTW: API implementors don't generally design their API around the unit-testing requirements of the API's users. Please don't test the API I wrote; I've already tested it. Test your own code.