starred/rspotify

Fork 0

mirror of https://github.com/ramsayleung/rspotify.git synced 2026-04-25 23:45:52 +03:00

[GH-ISSUE #296] Automatically do paginated post requests #89

New issue

Closed

opened 2026-02-27 20:23:03 +03:00 by kerem · 5 comments

kerem commented

2026-02-27 20:23:03 +03:00

Owner

Originally created by @nick-lehmann on GitHub (Jan 20, 2022).
Original GitHub issue: https://github.com/ramsayleung/rspotify/issues/296

Is your feature request related to a problem? Please describe.

After gathering some information from the Spotify API, I tried to add around 300 tracks to a single playlist. I knew that Spotify restricts the number of items that can be passed to an endpoint. For the Add Items to Playlist endpoint, Spotify imposes a limit of a 100 tracks in a single request. The API does not reflect this restriction in any way.

Describe the solution you'd like

While it would be possible to add some type information to functions like playlist_add_items, I would rather prefer that all method do chunking automatically. If the given number of items surpasses the limit of the API, a second request will be sent.

Describe alternatives you've considered

It is quite easy to implement the chunking on my own. However, it is dull and the returned responses with a status code of 400 might surprise some users.

Additional context

I am quite new to Rust and, given you agree to this proposal, I would love to create a PR for this.

Originally created by @nick-lehmann on GitHub (Jan 20, 2022). Original GitHub issue: https://github.com/ramsayleung/rspotify/issues/296 **Is your feature request related to a problem? Please describe.** After gathering some information from the Spotify API, I tried to add around 300 tracks to a single playlist. I knew that Spotify restricts the number of items that can be passed to an endpoint. For the [Add Items to Playlist](https://developer.spotify.com/documentation/web-api/reference/#/operations/add-tracks-to-playlist) endpoint, Spotify imposes a limit of a 100 tracks in a single request. The API does not reflect this restriction in any way. **Describe the solution you'd like** While it would be possible to add some type information to functions like [playlist_add_items](https://github.com/ramsayleung/rspotify/blob/52e35c8e4136e4895b0514766a44a2121bc498ba/src/clients/oauth.rs#L296), I would rather prefer that all method do chunking automatically. If the given number of items surpasses the limit of the API, a second request will be sent. **Describe alternatives you've considered** It is quite easy to implement the chunking on my own. However, it is dull and the returned responses with a status code of 400 might surprise some users. **Additional context** I am quite new to Rust and, given you agree to this proposal, I would love to create a PR for this.

kerem

2026-02-27 20:23:03 +03:00

closed this issue
added the
enhancement

Stale
labels

kerem commented

2026-02-27 20:23:04 +03:00

Author

Owner

@ramsayleung commented on GitHub (Jan 23, 2022):

Hi Nick, this idea sounds great!

Rspotify just supports automatically fetch the paginated requests, but it doesn't support automatically feed the paginated requests. It will be great if you could help us add this feature.

@ramsayleung commented on GitHub (Jan 23, 2022): Hi Nick, this idea sounds great! `Rspotify` just supports automatically **fetch** the paginated requests, but it doesn't support automatically **feed** the paginated requests. It will be great if you could help us add this feature.

kerem commented

2026-02-27 20:23:04 +03:00

Author

Owner

@marioortizmanero commented on GitHub (Jan 23, 2022):

I think in this case there's no nerd to have a _manual and an iterator version right? Mainly because it doesn't really work with pages. It could just work transparently for user friendliness, as long as it's clearly commented.

@marioortizmanero commented on GitHub (Jan 23, 2022): I think in this case there's no nerd to have a _manual and an iterator version right? Mainly because it doesn't really work with pages. It could just work transparently for user friendliness, as long as it's clearly commented.

kerem commented

2026-02-27 20:23:04 +03:00

Author

Owner

@nick-lehmann commented on GitHub (Jan 24, 2022):

@ramsayleung thank you very much, I will try to get a PR going this week 👍🏻

@marioortizmanero I guess there is a always a nerd 😝 But no, I don't think we would need both. I don't see why anyone would need the manual version...

@nick-lehmann commented on GitHub (Jan 24, 2022): @ramsayleung thank you very much, I will try to get a PR going this week 👍🏻 @marioortizmanero I guess there is a always a nerd 😝 But no, I don't think we would need both. I don't see why anyone would need the manual version...

kerem commented

2026-02-27 20:23:04 +03:00

Author

Owner

@github-actions[bot] commented on GitHub (Jul 2, 2023):

Message to comment on stale issues. If none provided, will not mark issues stale

@github-actions[bot] commented on GitHub (Jul 2, 2023): Message to comment on stale issues. If none provided, will not mark issues stale

kerem commented

2026-02-27 20:23:04 +03:00

Author

Owner

@github-actions[bot] commented on GitHub (Nov 29, 2025):

Message to comment on stale issues. If none provided, will not mark issues stale

@github-actions[bot] commented on GitHub (Nov 29, 2025): Message to comment on stale issues. If none provided, will not mark issues stale

kerem referenced this issue

2026-02-27 20:23:54 +03:00

[PR #89] [MERGED] Add blocking add_item_to_queue #238