Skip to content
This repository has been archived by the owner on Feb 14, 2023. It is now read-only.

Wrong upload_id example in the specification at /athlete/activities #44

Open
paleloser opened this issue Dec 15, 2022 · 1 comment
Open

Comments

@paleloser
Copy link

paleloser commented Dec 15, 2022

The developers site states that, at /athlete/activities the returned upload_id through SummaryActivity has type long. Yet, the response example you provide:

[ {
  "resource_state" : 2,
  "athlete" : {
    "id" : 134815,
    "resource_state" : 1
  },
  "name" : "Happy Friday",
  "distance" : 24931.4,
  "moving_time" : 4500,
  "elapsed_time" : 4500,
  "total_elevation_gain" : 0,
  "type" : "Ride",
  "sport_type" : "MountainBikeRide",
  "workout_type" : null,
  "id" : 154504250376823,
  "external_id" : "garmin_push_12345678987654321",
  "upload_id" : 987654321234567891234,
[...]

Provides an upload_id which doesn't complain with the specification, as int64's max value is 9223372036854775807, which is less than 987654321234567891234. This may be important because it makes more complex to create integration tests mocking the API using the provided examples.

@paleloser
Copy link
Author

Apparently, that's not the only field wrong in the example. There are several other fields mentioned in the example which don't comply with the SummaryActivity specification, such as resource_state, max_heartrate, location_city and more. And the same applies to objects within this specification like map, which also includes resource_state.

In addition to these, I strongly suggest sorting the Models/Components in the side navbar of the documentation site alphabetically. They way they are presented at the moment complicates a lot searching for a specification.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant