Rest api should follow some pattern

Hey!

i have found couple of things which propably should be consistent, across the plugins/services.

  1. Not all elements flagged as “type : song” does carry the artist name. (ie. spotify -> “my top tracks”)

rest api data model should contain artist field allready, so it should be matter of packing it to the response, no changes required anywhere else.

  1. Type of element in higher hierarchy of navigation(ie. service/plugin “root”) feels like a mess currently
  • “streaming-category”
  • “spotify-category”
  • “playlist”
  • “folder”
  • “item-no-menu”

are all these really needed for something(this is just from spotify and tidal, the list is huge with everything)? or should there be X amount of predefined types, which every plugin should follow.

Edit:
3. To continue lets take an example of spotify plugin, from the “root” of service, we have an item “what’s new”, this does contain ALBUMS(as per spotify uri), not an folders as the type says what rest api does return.
Album should contain artist and the actual album name, now it does not.

  1. The object model as whole in rest api
    root element is not needed at all, child of root does contain an object that should be the root object and “previous”, previous should be deleted as backend is not responsible for UI state keeping, useless bytes transferred, use these for something useful if data usage is consern.(look above)

as Customer, im starting to feel bit frustrated because the advertised features are not really working, or are just implemented with braindead attitude of “we got biggest feature list” without actually providing anything usefull.

2 Likes