[GH-ISSUE #234] Use an external HTTP universal interface instead of `rspotify-http` #79

New issue

Closed

opened 2026-02-27 20:22:59 +03:00 by kerem · 3 comments

kerem commented

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

Owner

Originally created by @marioortizmanero on GitHub (Jul 15, 2021).
Original GitHub issue: https://github.com/ramsayleung/rspotify/issues/234

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

Ever since we abstracted away the HTTP clients into the BaseHttpClient trait I've wanted to consider making it a public crate outside of rspotify. The current rspotify-http should just be a dependency, and worked on externally. Separating the module into the rspotify-crate was the first step. Not only would we actually separate http logic from spotify's API, but also have support from the community and reduce the maintenance work needed for Rspotify.

This isn't really a top priority right now as it might be a bit complicated, but ideally it should be released before v0.11 in order to avoid confusion.

Describe the solution you'd like

I think the best way to handle the HTTP client abstraction would be to create a separate crate, as I can imagine it's a frequent problem for other API wrappers like us and we could do with some support from other developers outside of Rspotify. This way it'll be much easier to add new clients.

After investigating a bit I've found the following already-existing crates:

fMeow/uclient, from the creator of maybe_async, just what we're looking for. Problems: (1) seems a bit abandoned currently, (2) uses maybe_async, so #221 remains unsolved. @fMeow, do you plan on maintaining the crate any further?
http-client: "Types and traits for http clients", very similar and well maintained. Not sure if it's the exact same as uclient, I should try it out. Problems: I think it only supports asynchronous clients currently.

Other crates that implement HTTP interfaces with maybe-async:

Originally created by @marioortizmanero on GitHub (Jul 15, 2021). Original GitHub issue: https://github.com/ramsayleung/rspotify/issues/234 **Is your feature request related to a problem? Please describe.** Ever since we abstracted away the HTTP clients into the `BaseHttpClient` trait I've wanted to consider making it a public crate outside of rspotify. The current `rspotify-http` should just be a dependency, and worked on externally. Separating the module into the `rspotify-crate` was the first step. Not only would we actually separate http logic from spotify's API, but also have support from the community and reduce the maintenance work needed for Rspotify. This isn't really a top priority right now as it might be a bit complicated, but ideally it should be released before v0.11 in order to avoid confusion. **Describe the solution you'd like** I think the best way to handle the HTTP client abstraction would be to create a separate crate, as I can imagine it's a frequent problem for other API wrappers like us and we could do with some support from other developers outside of Rspotify. This way it'll be much easier to add new clients. After investigating a bit I've found the following already-existing crates: * [fMeow/uclient](https://github.com/fMeow/uclient), from the creator of `maybe_async`, just what we're looking for. Problems: (1) seems a bit abandoned currently, (2) uses `maybe_async`, so #221 remains unsolved. @fMeow, do you plan on maintaining the crate any further? * [http-client](https://github.com/http-rs/http-client): "Types and traits for http clients", very similar and well maintained. Not sure if it's the exact same as uclient, I should try it out. Problems: I think it only supports asynchronous clients currently. Other crates that implement HTTP interfaces with `maybe-async`: * https://gitlab.com/qonfucius/aragog * https://github.com/fMeow/arangors

kerem

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

closed this issue
added the
enhancement

Stale
labels

kerem commented

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

Author

Owner

@marioortizmanero commented on GitHub (Sep 15, 2021):

We should probably do this after #221, since it may change the way Http clients work.

@marioortizmanero commented on GitHub (Sep 15, 2021): We should probably do this after #221, since it may change the way Http clients work.

kerem commented

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

Author

Owner

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

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

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

kerem commented

2026-02-27 20:23:00 +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