Control MPD via REST API

[roizcorp]

Feature request

I think it would be worthwhile to expose a rest api so clients and users can control and retrieve information from MPD. Yes, there's the awesome mpc client and the others, but the rest api kind of standardizes the interface and makes MPD agnostic to the clients.

For an instance, now, in order to be client agnostic I'm interfacing with MPD via netcat or telnet, but rest could be more robust with the responses such as long playlists via json and what not. I found a GitHub project that started to address this, but it has been deserted and really that would be much preferable if it could be out of the box or at least an MPD plugin I can turn on and off according to my use with MPD

https://github.com/christianwicke/togglempc

[MaxKellermann]

This has been requested a few times over the last 2 decades, but I'm not interested in spending time on this.

[NexAdn]

Is it really a good idea to having to maintain two APIs? Also, most languages probably have a client library for MPD by now, so I don't see much benefit in providing a second API. And removing the existing API is also not an option, since that would break every single existing client out there for no good reason.

A REST API might be nice for sure, but I don't see the benefits weighing out the extra burden it puts on the maintainer(s) of this project.

[MaxKellermann]

No, there shouldn't be more than one API - and that "togglempc" project is an example how it should not be done - it specifies a completely new protocol transported over HTTP.

What would be possible is tunnel regular MPD commands through HTTP requests (or WebSocket). That way, web interfaces could use this interface instead of having to implement their own HTTP/MPD bridge, and all new protocol features would be available immediately.

But anyway, I'm not interested in implementing this - I'm not intersted in any web interfaces or HTTP APIs - I'm just trying to outline what could maybe be acceptable and what would certainly not be.

[roizcorp]

Although both of you said no, @MaxKellermann's comment is more soothing :)
I'm not a developer, I'm a product manager...I think of a potential for any software to be able to grow on its own and to develop (or maintain) an ecosystem.
Clearly, I respect your decision, and I'm very grateful for what you do for MPD, but may I ask why you're not interested? Is it because it is not an actual "feature" that is music playing related? Or did HTTP do something to you in the past? :)

[MaxKellermann]

Or did HTTP do something to you in the past? :)

Ha ha, no, actually I do HTTP all day at dayjob - I wrote a whole web server that runs millions of websites :-)

I'm not convinced that adding a HTTP API to MPD will be very useful. That's just my personal taste. The day has only so many hours - if I'd spend time on such a HTTP API, I would have less time for things I consider more important, it's that easy. There are so many things I'd like to hack into MPD, but there's so little time, so I have to choose wisely.

If there are so many people who believe a HTTP API is important, they should implement it. Don't expect somebody else to do it, just do it yourself.

[roizcorp]

Do you maintain a roadmap vision (or to-do list) somewhere, so people can review and comment? (I'm actually against voting for features, but that's another conversation)
Perhaps that would help you add features that are more mature, or just get the reception of your ideas before actually doing them

[MaxKellermann]

I have no (written) roadmap, only numerous ideas in my head. I don't think discussing those ideas is helpful as long as I don't have the time to implement them. And even if I do have time to implement them, comments/reviews don't help a lot. Everybody who has enough interest in MPD should write code instead of reviews. That's the only thing that really counts.

[mxjeff]

I also believe a good approach would be to expose regular MPD protocol over a websocket (cf. #1511).
Just leaving the message to reference the websocket issue already reported here.