Well done for taking the initiative!
I’m interested (feel free to move this into the new forum if you like) - are you modelling this approach on another project?
What do you mean?
About the approach I deal with media centers since more than a decade and general project management since way longer 
I know how complex and difficult it is to have multiple people agreeing on changing things in a common direction. It’s already hard in a single project so if you expand to multiple project at once it starts to be a nightmare.
Hence the nearly everything optional, all discussion based approach. The only mandatory things being that servers identify themselves properly so that clients can properly adapt to each servers choices.
Yeah - I meant, at the meta level, about how to manage a project like this. Intuitively, your “extensions” approach seems appropriate because it sets a low bar for minimum-viable compliance.
One thing i’d like to put out there before moving onto the forum is that we should decide on some things.
First I would suggest that 1.16.1 is used as the base of this extension with a goal of releasing as a new version like 2.17.0/1.17.0.
On top of that I would also suggest that we avoid changing anything currently in 1.16.1 that would alter the methods. (e.g. only add new methods on top of the old ones.) This would allow full support for all compatible clients and allow opt-in support for anyone moving up.
That way it’s very clear that if your server supports 1.17.0+ you know what you can use without having to decide what your client can use adhoc based on the server.
Is this the same sort of feeling from others?
Well I guess my English is not that good but I tried to explain here and there why I do not think this is a good idea.
Forcing all servers to 1.16.1 + having a new API number force servers to implement everything in the new API. (For the moment I’m even requesting 1.13 because of Ampache ;))
And even 1.16.1 does not really means anything anymore since nearly no server implements the whole API and many have end points returning not implemented.
While having a proper schema version for a single app is nice and good in the long term, I do not think this fit nicely with the current eco system.
This puts a tons of burden on the server devs, the proposal is something a lot more pragmatic.
If we put tons of work on all servers devs just to start supporting the extension it will never happens. It would require more servers following the trends and much much more clients to encourage them to do so.
I explain nearly everything on the subforum. Including how we can still do backward compatible changes to current API without impacting any of the current clients.
And to clarify giving server name is also very helpful for current situation (and future) an open API can’t describe all the edge cases and servers will have differences no matter what.
And this would still allow you to stay at 1.13 so not implementing the new auth scheme and directly the extended one.
Because let’s be honest saying I’m 1.16.1 but disabling the new auth with a fake ldap error means you are effectively 1.13.1.
Hi, trying to catch up on this thread. I’m definitely interested in resurrecting an effort to expand the API. I wrote a proposal for extension endpoint versioning here: proposals/endpoint-naming-and-versioning.md · ea4408ae23621aae3cb76605dc9e1ed85935c4ef · Sonic Extensions API / Specification · GitLab
I’d want to move the project to GitHub. Let me know if you’d like me to do that.
The question about your proposal is what does versioning of the API brings over the last part of your proposal (That match mine, see the OpenSubsonic API extensions - Symfonium support part of the forum) [Expose supported extensions]
The goal is really to limit the burden to the servers devs to the minimum, adding a versioning API means they need to comply with it and all the end points. And if in all cases the clients needs to check what is supported or not if a server does not implement everything then it does not bring much.
We just need to ensure a conflict free or versioning of each of the extensions.
So in your case /rest/extensions/supportedEndpoints (Would change the name to support other addition than endpoints, like supporting post, or just new authentification system) it could return a list of function with versions.
In json would be
[ { "authentication": 1}, {"songArtists": 2}, ...]
IMO also as said in the answer to @lachlan-00 we should allow non breaking change to current API to again remove some work on the server side.
Like if we want to return new fields to media, it would requiring adding new versions of all the current calls that can return media, that’s a huge amount of work for no gain.
In that case it’s easier to just write a new better API from the start.
TL;DR: If we add too much rigidity and force many new endpoints for small changes, it’s probably better to directly write a proper V2 API schema that would be better and future proof. But that’s another story and much harder to convince everyone to see a benefit in it.
That would mean like 3 API for Ampache, they would have no reason to generate more work for them for any internal change they make to still maintain all those API.
I’ve added you to the group on the subforum.
Hello,
Maintainer of GitHub - epoupon/lms: Lightweight Music Server. Access your self-hosted music using a web interface. here, which exposes an optional Subsonic API.
Interested in the discussion
Nice I’ve added you do the group.
Can you add a description to your account so all others know what you represent?
1 Like
Hi! I’m working on a new Subsonic desktop client GitHub - dweymouth/supersonic: A lightweight cross-platform desktop client for Subsonic music servers. Not ready for alpha release yet but it’s getting close. I found this forum from the Reddit selfhosted thread. I’d like to be added to the group as well, thank you!
Added, please add a description to your account.
Hello 
Supysonic dev here.
I’m curious to see where this effort will lead to. I have some comments about the API but until I’m given posting permissions to the dedicated section I’ll just restrict myself to some basic points.
Adding anything to the responses could be considered as a breaking change, to some extent. I guess nowadays the vast majority of clients are using the JSON format so it might be a moot point but for those using XML, the responses follow a specific schema defined by a XSD; adding a new attribute or node without publishing the associated schema could lead to schema validation errors (assuming clients validate the responses against the XSD). Supysonic is using this XSD by the way, not at runtime but within its test suite.
Regarding authentication, we all seem to agree something needs to be done.
When I started working on Supysonic the API was at version 1.8.0. Using what should be common sense I stored the passwords after hashing them, which prevented me from implementing the so-called token authentication introduced with version 1.13.0 (which I won’t implement, for obvious reasons). But this never was a problem for Supysonic since it never reached this API version.
I don’t remember how I got this, if this was by testing some clients or the official server (as it’s undocumented), but it seems Subsonic supports HTTP Basic Authentication. Even if this isn’t much in safety terms (disregarding HTTPS), clients should use it instead of the u and p query parameters and it shouldn’t be too much of a change for those that don’t support it yet. At least this way the credentials won’t be disclosed in web server logs.
I’ve added you to the group.
Nearly all servers returns additional data in the subsonic-response already to indicate the type of server. And many report additional stuff in some or the other answers. Not talking about undocumented answers to not implemented endpoints. So we are already quite past the pure XSD implementation, currently there’s not even 2 servers that are 100% identical in their answer.
About auth, HTTP basic auth is the same as using enc: so would not really bring something, I would tend to say it’s even worse as all the tools scrape that data, while a subsonic specific parameter may not be (But anecdotal difference)
And in the end sending login and password requires the client apps to also store that, having tokens and/or API keys also brings user security to workaround the usual user that use the same login/password on many sites.
With that said, don’t know if it’s already the case but already supporting Explicit server name and version and Search3 endpoint clarification would be nice since all the other servers currently involved do support them and simplify client life a lot.
This topic is now archived as the goal is achieved.
See GitHub - opensubsonic/open-subsonic-api: Repository hosting the definition and discussions of the Open Subsonic API for the resulting public OpenSubsonic organisation.