Access to websockets

Reply
Highlighted

Access to websockets

Casual Listener

Hi, I'm re-opening an issue that has been closed (#817), ignored (#1330, #538), or locked (#492) time and again.

 

While I'm very thankful for the APIs Spotify provides developers, the lack of transparency/availability regarding the WebSocket APIs is making this a frustrating platform to develop for. This is further exacerbated when one reads through issues that are over a year old, saying that Spotify is still working on bringing public WebSocket APIs to third-party clients.

 

Additionally, though I will not go into detail, Spotify literally has WebSocket APIs that it uses for its web client. Why can't these APIs be made available to third-party users? They seem pretty data-rich to me, and stable enough to be deployed to your production software.

 

Moreover, I plead that the developers respond openly to this, whether WebSockets are coming or not, and not something opaque such as "the more time we spend on making sure people aren’t ‘investigating’ non-public APIs that they’re not authorised to access, the less time we can spend on making these APIs ready to be available to the public" (#817). This is not only unhelpful, but a childish response to a valid request. It was valid in 2018, and frankly, is even more valid in 2020.

Please, please release a public WebSocket API. Polling the API every few seconds is disgusting, wasteful for your servers and ours, and rate-limit prone.

 

x-post from https://github.com/spotify/web-api/issues/1558

10 Replies
Highlighted

Re: Access to websockets

Casual Listener

Seconded!


Not only are there countless people behind me who want this feature, I need it because I'm writing an app to control a dancing robot (Google: My Keepon) and that needs realtime information of playback (so it dances in time to the music*).

 

What I don't wanna do is repeatedly hammer the Spotify /v1/me/player/currently-playing endpoint every 1000 ms and compare changes between each request before then hitting /v1/audio-analysis/{id} to get "dance" data, only to then be out of sync.

 

I would dearly love a Spotify WebSocket that can just tell me the track / playback status has changed and this would save both mine and Spotify's resources all round.

 

* For anyone who cares, this is the robot in question, and yes, I love my RGB; https://www.dropbox.com/s/pp17jen51rqe2hb/2020-05-12%2013.54.17.mp4?dl=0 

Highlighted

Yes please.

Casual Listener

I could not have put this in better words.

We feel ignored and stranded with this lack of transparency, and as EricRabil1 already wrote:

Polling the API every few seconds is disgusting, wasteful for your servers and ours, and rate-limit prone.

 

Personal opinion / guess:

I think spotify has no reason to provide public websockets other than saving server resources (also one would have to investigate if websockets would cause more network traffic and therefore problems).

Allowing developers to build awesome realtime projects is not good for them because someone could then build a ad-free spotify-client clone which would lead users away from their own client.

 

I understand that, and I would be perfectly fine if someone from spotify would finally admit that we wont get websockets because they would lose money or something, but they just stay silent.

This just hurts the image of spotify as my personal opinion now is "If spotify cant make even more money out of a feature they dont care."

 

Another option would be offering partnership deals, paying money to be able to use the websockets in a way spotify is fine with. For example discord, there the websockets are used only to display the current track and time.

 

I feel like nothing I try to program with spotify is worth the effort

Highlighted

Re: Access to websockets

Casual Listener

Track/Playback status changes near realtime is needed for a genuine use of the Spotify web api.

 

It's conceptually wrong imho to require applications to continuously poll the api to get those vital informations. Without this we create slow response applications (with very bad user experience), high api requests/second falling to high ratelimited requests (with very bad user experience) and probably high load server side (both consumer and spotify).

 

I think that creating a callback api with auto retry (eg I really really love the callback api implemented by telegram bots) can increase the spotify app ecosystem a lot.

Thank you!!

Highlighted

Re: Access to websockets

Casual Listener
Yes, webhooks or callbacks would be another awesome thing, it would not require a constantly open TCP connection but instead only small-payload GET/POST requests to an endpoint on consumer side that indicates track and/or playback changes
Highlighted

Re: Yes please.

Casual Listener
I really don't think that playback status change notification via callback api is sufficient to implement a spotify client clone with no ads... Why do you think so?
Highlighted

Re: Yes please.

Casual Listener

@CodingKiwi I see where you're coming from, though I would argue that @dinospot has a fair counterclaim that I'd like to build on.

 

Given Discord presences are realtime, you could theoretically build an API that pulls the Spotify presence from your Discord presence and you'd have a lot of metadata right there. But you'd be missing some key information, like the track ID.

 

Because this data is still freely available to Discord developers in realtime, it doesn't make much sense for Spotify to not provide similar functionality through their own APIs.

Highlighted

Re: Yes please.

Casual Listener

I concur, having a playback status change websocket doesn't circumvent subscription level.

Highlighted

Re: Yes please.

Spotify
Spotify

@BagJason, that robot is impressive 🙂

 

@EricRabil1 @dinospot @CodingKiwi Thank you for letting us know that this is something you'd like to see. I will be sure to share your feedback with other folks on the team.

Highlighted

Re: Yes please.

Casual Listener
@spotifyjosh Thank you bud, we look forward to hearing from them.
It makes sense really, it will actually _reduce_ load on the Spotify API servers and at least 90% of the code should be there from the Spotify Web Player 🙂
SUGGESTED POSTS