[API Request] All new apis should use the same entity names when referring to a given entity

[dbrader]

Type of change

API Clarification

Proposal description

All future apis should use consistent naming for entities. Having incomplete or differently named entities in the api cause a huge headache.

For example, Songs have a entity name of entry, song, match depending on what api you call.

Also the property list is different depending on the api.

Can't we all just agree that a song is a "song", an album is an "album"?

My code wants things to be named the same and not have to special case given apis :)

Backward compatibility impact

Changing entity names in the current api would break them. Lets move forward being consistent from this point.

Backward compatibility

• No backward compatibility impact.

API details

a song is a "song" everywhere. Same for all other entities... an album is an "album" etc

Security impacts

none

Potential issues

No response

Alternative solutions

No response

[Tolriq]

A large part is tied to Subsonic having 2 modes folders or tags.

Should we also drop the non ID3 concept for the new endpoints?

[dbrader]

Yes, the dual mode is troubling. Especially when you need to mingle the two to get the info required. And have the web interface in one but use the other in your client.

In my opinion, we should have one or the other (preferably ID3 only everywhere). But I understand others would vehemently disagree and shout me off the ledge. ;)

Its hard to be all things to all people.

[lachlan-00]

I agree with dropping the id3/file separation. In Ampache the concept of files/folders is really just parent and child relationships between these objects. (Catalog folder => Artist => Album => Song)

I'm happy to provide the folder/id3 split in the old api as is but would agree with moving to a id3 object for new works. we could also include the parent attribute in these new objects and just merge them into one object.

[spl0k]

Well, I would advise against dropping the separation. That's not my case but I know some users have a file storing scheme other than what might be the usual Artist/Album/Song, and they like being able to browse their library the same way it's stored on their drive. This might be the case for people that use Subsonic and compatibles not only for music but also for podcasts and audiobooks, where the Artist-Album-Song paradigm doesn't make much sense, but I can also imagine some scenarios where it might be useful for music (like adding other layers for the release type for instance, separating singles from EPs and albums).

Nevertheless if we keep the folder concept it should stay what it actually represents: a folder, and not try to add some other concepts on top of it based on false assumptions like "this folder is an album because it contains audio files, therefore the parent folder is an artist", something the current API seems to do (explaining the existence of two similarly named entities such as Artist and ArtistID3 for instance).