Inconsistent handling of trailing commas in the ids param for /v1/tracks & /v1/audio-features

[Noxshus]

Issue found on 5th May 2020

Endpoint(s):

• `GET /v1/tracks'
• 'GET /v1/audio-features'

Scope(s):

• None (neither request needs one)

Steps to reproduce:

Context: Both these calls have a query parameter called "ids". "ids" accepts a comma delimited string of Spotify IDs for tracks. However, "/v1/audio-features" will handle a trailing comma, while "/v1/tracks" does not. This can be most easily reproduced via the examples in their respective references -

1. Navigate to /v1/audio-features. Scroll down, click "Try it"
2. Get a token (if you don't have one)
3. Add an extra comma at the end of the ids string, e.g. 4JpKVNYnVcJ8tuMKjAj50A,2NRANZE9UCmPAS5XVbXL40,24JygzOLM0EmRQeGtFcIcG,
4. A successful reply is recieved.

---

1. Repeat the same process for /v1/tracks.
2. Reply is a 400 error.

Expected behaviour:

It would be ideal if behaviour was consistent across both calls, as the parameter has the same name & both calls are sorted under the same "Tracks" section in the reference document. A user is likely to assume they share the same/similar logic.

I suspect that the intended behaviour is that "/v1/audio-features" shouldn't accept a trailing comma, particularly because JSON objects aren't supposed to accept them.

Actual behaviour:

The following is recieved, in the case of "/v1/tracks":

{
"error": {
"status": 400,
"message": "invalid id"
}
}

In the case of "/v1/audio-features":

{
"audio_features": [...]
}