Feature Request: Add IDs Endpoint

[obrhoff]

Feature Request: Add ID's Endpoint

Currently it's not possible to fetch only the Ids of the followers/favorites etc. That makes it really ressource intensive to figure out, which tracks the user has a relationship since we need to page through a lot of data. (the details of the tracks or users are not needed here).

API-v2 is providing this functionality. It would be to see this in the API.

Endpoint(s):

• GET /users/{id}/followings/ids
• GET /users/{id}/followers/ids
• GET /users/{id}/favorites/ids
• GET /users/{id}/reposts/ids

[rahul-sc]

Hey @DocterD What do you mean by "..which tracks has a relationship.."? What is your actual use case here?

Also, have you checked out the updated API spec here?
https://developers.soundcloud.com/docs/api/explorer/open-api

There's already functionality supporting the retrieval of paginated collection of likes, follows, reposts etc

[obrhoff]

Imagine you got a stream of Tracks and you want to figure out which one are already liked or reposted. Performance wise it makes sense to just retrieve and store the ID's of the favorited/reposted tracks and match these against incoming tracks.

Right now you need to page through the Liked/Reposts endpoint which is quite heavy since we speak about potentially hundreds or thousands of liked tracks.

[rahul-sc]

Thanks for the additional context @DocterD

I suppose the alternative here would be that the server could do that for you and represent the relationship of that entity back to the authenticated user, no? For example, the track response already has "user_favorite": true to indicate if the user liked the track.

[obrhoff]

That might work.

It should be added for the additional states (reposted/following/follower). For consistency It would make sense to move to user_liked instead of user_favorite. It confused me that sometimes the favorite and sometime liked term is used for the same thing.