starred/go-librespot

Fork 0

mirror of https://github.com/devgianlu/go-librespot.git synced 2026-04-26 13:25:49 +03:00

next API Compatibility with librespot-java #129

New issue

Closed

opened 2026-02-28 14:25:38 +03:00 by kerem · 5 comments

kerem commented

2026-02-28 14:25:38 +03:00

Owner

Originally created by @iVolt1 on GitHub (Aug 21, 2025).
Original GitHub issue: https://github.com/devgianlu/go-librespot/issues/198

Currently, the go-librespot /player/next endpoint requires a POST body (even an empty JSON object) where as the librespot-java /player/next endpoint does not require a POST body . This breaks go-librespot compatibility with Home Assistant’s media player, which sends the /player/next request without a body. Aligning the go-librespot behavior with librespot-java would improve integration and allow me to move forward cleanly with my new music addon for Home Assistant.

This issue was previously reported in https://github.com/devgianlu/go-librespot/issues/151 .

This is probably a one or two line code change, so if any of the developers here could create a pull request for this, it would be greatly appreciated.

Thanks for your excellent work on this project—go-librespot has been rock-solid in my setup and offers great performance and reliability.

IVolt1

Originally created by @iVolt1 on GitHub (Aug 21, 2025). Original GitHub issue: https://github.com/devgianlu/go-librespot/issues/198 Currently, the go-librespot /player/next endpoint requires a POST body (even an empty JSON object) where as the librespot-java /player/next endpoint does not require a POST body . This breaks go-librespot compatibility with Home Assistant’s media player, which sends the /player/next request without a body. Aligning the go-librespot behavior with librespot-java would improve integration and allow me to move forward cleanly with my new music addon for Home Assistant. This issue was previously reported in https://github.com/devgianlu/go-librespot/issues/151 . This is probably a one or two line code change, so if any of the developers here could create a pull request for this, it would be greatly appreciated. Thanks for your excellent work on this project—go-librespot has been rock-solid in my setup and offers great performance and reliability. IVolt1

kerem closed this issue

2026-02-28 14:25:38 +03:00

kerem commented

2026-02-28 14:25:38 +03:00

Author

Owner

@devgianlu commented on GitHub (Aug 21, 2025):

I see why you would want this change, but having the request be a GET is a bad design choice and won't be implemented. I think the best course of action is to get the Home Assistant plugin updated.

@devgianlu commented on GitHub (Aug 21, 2025): I see why you would want this change, but having the request be a GET is a bad design choice and won't be implemented. I think the best course of action is to get the Home Assistant plugin updated.

kerem commented

2026-02-28 14:25:38 +03:00

Author

Owner

@iVolt1 commented on GitHub (Aug 21, 2025):

My apologies if I was not clear, try as I may, so please allow to give it another try. Changing the POST to a GET is not what I am suggesting.

As you replied to stronk-dev in https://github.com/devgianlu/go-librespot/issues/151, "You should be able to make a POST request to /player/next with an empty JSON object as body. The uri field is not mandatory."

The problem is that a POST request to /player/next with a JSON object as body is mandatory in go-librespot, but a JSON object as body is optional in a POST request to /player/next in librespot-java. The API in Home Assistant does not include a JSON object for a POST request to /player/next so the POST call fails with go-librespot.

Allowing the go-librespot API to accept a POST request to /player/next without a JSON object as body is what I am requesting.

This is the only difference in API behavior I have seen between librespot-java and go-librespot. I tried looking through the code of both of those librespot versions to pinpoint what needs to be done, but it is beyond my capabilities at this time.

Thanks,

iVolt1

@iVolt1 commented on GitHub (Aug 21, 2025): My apologies if I was not clear, try as I may, so please allow to give it another try. Changing the POST to a GET is not what I am suggesting. As you replied to [stronk-dev](https://github.com/stronk-dev) in https://github.com/devgianlu/go-librespot/issues/151, "You should be able to make a POST request to /player/next with an empty JSON object as body. The uri field is not mandatory." The problem is that a POST request to /player/next with a JSON object as body is mandatory in go-librespot, but a JSON object as body is optional in a POST request to /player/next in librespot-java. The API in Home Assistant does not include a JSON object for a POST request to /player/next so the POST call fails with go-librespot. Allowing the go-librespot API to accept a POST request to /player/next without a JSON object as body is what I am requesting. This is the only difference in API behavior I have seen between librespot-java and go-librespot. I tried looking through the code of both of those librespot versions to pinpoint what needs to be done, but it is beyond my capabilities at this time. Thanks, iVolt1

kerem commented

2026-02-28 14:25:38 +03:00

Author

Owner

@devgianlu commented on GitHub (Aug 30, 2025):

Ah I see what you mean now

@devgianlu commented on GitHub (Aug 30, 2025): Ah I see what you mean now

kerem commented

2026-02-28 14:25:39 +03:00

Author

Owner

@devgianlu commented on GitHub (Aug 30, 2025):

Should be good now, you can make a request with an empty POST body.

@devgianlu commented on GitHub (Aug 30, 2025): Should be good now, you can make a request with an empty POST body.

kerem commented

2026-02-28 14:25:39 +03:00

Author

Owner

@iVolt1 commented on GitHub (Aug 30, 2025):

Thank you for completing this! I was working on my first ever PR for this but it looks like you made some more comprehensive changes.

@iVolt1 commented on GitHub (Aug 30, 2025): Thank you for completing this! I was working on my first ever PR for this but it looks like you made some more comprehensive changes.