starred/rspotify

Fork 0

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

[GH-ISSUE #132] Partial model object with `fields` query parameter #45

New issue

Open

opened 2026-02-27 20:22:46 +03:00 by kerem · 7 comments

kerem commented

2026-02-27 20:22:46 +03:00

Owner

Originally created by @ghost on GitHub (Oct 7, 2020).
Original GitHub issue: https://github.com/ramsayleung/rspotify/issues/132

Some Spotify endpoints, especially the ones returning a paging object, allow to specify the fields that we want to fetch.

For example, Get a Playlist's Items has a fields query parameter that allow selection of fields, but we can't use it since it would raise an error when trying to deserialize the fields that are not specify :

// Return an Err(ErrorMessage { msg: "convert result failed,  reason: Error(\"missing field `album`\", ... })
spotify.playlist("37i9dQZF1DWXncK9DGeLh7", Some("tracks.items.track.(id,name)"), None);

This behaviour makes the fields parameter useless and forces to fetch data even if we don't need it. Solutions to that would be :

use #[serde(default)] on existing model object fields
use an Option on existing model object fields
create a new object model, for example PartialTrack, that implement either 1. or 2. and make endpoints that use a fields query parameter return such a Partial object instead of a Full or Simplified one.

I think 3. would be the most reasonable solution, moreover it might be possible to implement it using a macro.

Originally created by @ghost on GitHub (Oct 7, 2020). Original GitHub issue: https://github.com/ramsayleung/rspotify/issues/132 Some Spotify endpoints, especially the ones returning a paging object, allow to specify the fields that we want to fetch. For example, [`Get a Playlist's Items`] has a `fields` query parameter that allow selection of fields, but we can't use it since it would raise an error when trying to deserialize the fields that are not specify : ```Rust // Return an Err(ErrorMessage { msg: "convert result failed, reason: Error(\"missing field `album`\", ... }) spotify.playlist("37i9dQZF1DWXncK9DGeLh7", Some("tracks.items.track.(id,name)"), None); ``` This behaviour makes the `fields` parameter useless and forces to fetch data even if we don't need it. Solutions to that would be : 1. use `#[serde(default)]` on existing model object fields 2. use an `Option` on existing model object fields 3. create a new object model, for example `PartialTrack`, that implement either `1.` or `2.` and make endpoints that use a `fields` query parameter return such a `Partial` object instead of a `Full` or `Simplified` one. I think `3.` would be the most reasonable solution, moreover it might be possible to implement it using a macro. [`Get a Playlist's Items`]: https://developer.spotify.com/documentation/web-api/reference/playlists/get-playlists-tracks/

kerem commented

2026-02-27 20:22:47 +03:00

Author

Owner

@mendelsimon commented on GitHub (Aug 29, 2022):

I've run into this as well, and I agree with @Sydpy's conclusion.

@mendelsimon commented on GitHub (Aug 29, 2022): I've run into this as well, and I agree with @Sydpy's conclusion.

kerem commented

2026-02-27 20:22:47 +03:00

Author

Owner

@kangalio commented on GitHub (May 23, 2023):

I wonder if the additional complexity is even worth it. I feel like that Spotify API feature is mainly useful for dynamically typed languages, where specifying the fields you're working with is a quick low-effort change to reduce load. But in Rust, you'd have to use a different type, and then .unwrap() all the fields you're working with - a significant amount of friction. To keep rspotify's API simple, maybe this feature shouldn't be implemented?

@kangalio commented on GitHub (May 23, 2023): I wonder if the additional complexity is even worth it. I feel like that Spotify API feature is mainly useful for dynamically typed languages, where specifying the fields you're working with is a quick low-effort change to reduce load. But in Rust, you'd have to use a different type, and then `.unwrap()` all the fields you're working with - a significant amount of friction. To keep rspotify's API simple, maybe this feature shouldn't be implemented?

kerem commented

2026-02-27 20:22:47 +03:00

Author

Owner

@mendelsimon commented on GitHub (May 29, 2023):

I think there's enough value in this feature for it to not be abandoned. At the time of my previous comment, I had hacked together a proof of concept to test if it actually made a difference for my workflow (fetching the IDs of all tracks in a playlist), and the speed difference was significant.

@mendelsimon commented on GitHub (May 29, 2023): I think there's enough value in this feature for it to not be abandoned. At the time of my previous comment, I had hacked together a proof of concept to test if it actually made a difference for my workflow (fetching the IDs of all tracks in a playlist), and the speed difference was significant.

kerem commented

2026-02-27 20:22:47 +03:00

Author

Owner

@kangalio commented on GitHub (May 29, 2023):

a proof of concept to test if it actually made a difference for my workflow (fetching the IDs of all tracks in a playlist), and the speed difference was significant.

That is interesting. Can you share the benchmarking code?

@kangalio commented on GitHub (May 29, 2023): > a proof of concept to test if it actually made a difference for my workflow (fetching the IDs of all tracks in a playlist), and the speed difference was significant. That is interesting. Can you share the benchmarking code?

kerem commented

2026-02-27 20:22:47 +03:00

Author

Owner

@mendelsimon commented on GitHub (May 29, 2023):

That is interesting. Can you share the benchmarking code?

Unfortunately, it was just a quick hack job to informally test it and was not saved. If I recall correctly, it was pretty much copy-pasting the relevant structs and functions required to make it work, tweaking the struct to only save the ID (I don't recall if I made the other fields Optional or removed them entirely), and passing the fields parameter to only fetch the ID.

@mendelsimon commented on GitHub (May 29, 2023): > That is interesting. Can you share the benchmarking code? Unfortunately, it was just a quick hack job to informally test it and was not saved. If I recall correctly, it was pretty much copy-pasting the relevant structs and functions required to make it work, tweaking the struct to only save the ID (I don't recall if I made the other fields Optional or removed them entirely), and passing the `fields` parameter to only fetch the ID.

kerem commented

2026-02-27 20:22:47 +03:00

Author

Owner

@dylif commented on GitHub (Oct 22, 2023):

I've just ran into this issue. Forgive me if I'm missing something here, but why is the fields parameter provided if using it doesn't work?

@dylif commented on GitHub (Oct 22, 2023): I've just ran into this issue. Forgive me if I'm missing something here, but why is the `fields` parameter provided if using it doesn't work?

kerem commented

2026-02-27 20:22:47 +03:00

Author

Owner

@sandersantema commented on GitHub (Jan 2, 2025):

I think a fallback where a raw serde_json::Valueis returned would already be very nice. Such a solution would hopefully require the least amount of work to implement while still allowing for use of the fields functionality. The downside is that it would require some work on the side of the user of the library to handle the returned data, but even this does allow for a lot of flexibility.

@sandersantema commented on GitHub (Jan 2, 2025): I think a fallback where a raw `serde_json::Value`is returned would already be very nice. Such a solution would hopefully require the least amount of work to implement while still allowing for use of the fields functionality. The downside is that it would require some work on the side of the user of the library to handle the returned data, but even this does allow for a lot of flexibility.