Implementation in Deaftone

[112RG]

Wow I just found out about this after seeing it mentioned here http://support.symfonium.app/t/subsonic-servers-participation/1233/16?u=112 Which is talking about extensions to the current subsonic API. Well I would like to ditch that API because having routes such as getShares hurts me

I am wanting to start implementing this in Deaftone https://github.com/Deaftone/Deaftone and hopefully one have a defacto standard API for music servers and clients. The trouble is getting clients to support the API. I have already started on an early Desktop client https://github.com/Ortygia/Orpheus and will keep creating these even if nobody uses them. Because my drive is to fully replace subsonic apis / clients for my music streaming

[sampsyo]

Awesome!! It would be really fun to work on this. Indeed, developing a robust alternative to the Subsonic API is more or less the goal of AURA.

Please let us know how we can help or collaborate. I'm certain AURA needs to evolve, so please let us know how the spec seems out of date and we can keep working on it!

[112RG]

The API I have currently is here https://deaftone.org/api/ its smaller at the moment. But I do like the having a json response with data instead of just wrapping everything on the top level. I will change to that soon.

The only thing I am not sure is needed is

    "relationships": {
      "albums": {
        "data": [ { "type": "album", "id": "84" } ]
      }
    }

I am more inclined to just having a album_id on track returns almost exactly like the schema for for https://github.com/Deaftone/Deaftone/blob/master/entity/src/song.rs

I am might write a hackmd outlining the API spec I am thinking about and we can iterate on that

[sampsyo]

Sounds reasonable!

FWIW, some of the decisions that might look a little odd are a result of adherence to the JSON API spec. We used that as a kind of anti-bikeshedding reference point to avoid making too many "unique" decisions at the representational level. That seemingly-odd nesting relationships makes it possible for clients to automatically recognize that we're getting IDs that refer to other albums, rather than complete album data right there (which would be a useful alternative as well). I hope that makes sense!