Expose a releaseType String for albums when the server have the data.
Expose a mood String for albums when the server have the data.
Expose a styles String (Comma separated) for albums when the server have the data.
Expose a bpm Int for songs when the server have the data.
Expose a comment String for songs when the server have the data.
Server implementation status
I think returning a tags item is a good idea since it’s the most general, and clients can then be configured to treat certain tags as first-class citizens, or just display them as a key/value set. What might also be interesting is a new getByTags endpoint that retrieves all albums/songs that have a given tag (key=value) present. This could be used by clients to e.g. make the LABEL tag browsable, allowing a user to get a list of all albums released on the same record label (assuming their library was tagged as such, of course!)
The tags item could be returned as part of the album element to save data, IF all of the tracks in the album had the same value for a particular tag. Tags that were different per track within an album could be attached to the track element instead.
I guess a getTagValues endpoint would be a good idea too then, which returns all the values for a given tag in the library. So a client could present a list of composers by getting getTagValues(composer)
Yeah I guess that’s a good reason to keep them separate. In my library I’ve used multiple genre tags for the same purpose, putting the most specific genre first so it’s the one returned in the API but browsing by the broader genres still pulls in the appropriate albums.
In any case, both multi-genre support and style/mood support in the extended API would be a huge improvement.