Higher-level client methods / objects

[felix-hilden]

I have noticed a few cases where it could be useful to implement higher-level methods. With this issue I'd like to gather ideas about such methods, assess whether it would be worth it to implement them and how they should be implemented.

• Restore playback from playback context / playback start for objects (like Album)
• Change playlist details with a playlist object (get, modify attributes, update)

This issue is in no hurry to close. This functionality would be extra.

[marioortizmanero]

Not sure if these examples should go inside the API itself. They seem too specific to me, although I don't really know how much usage they'd get. It also depends on how easy they are to implement.

Instead of that, what about making an examples directory with these methods using the API? I think the original spotipy had one too, and it was quite helpful to learn the API.

[felix-hilden]

They would be fairly easy to implement. Changing a playlist's details with the object would just wrap the current function and accept a Playlist object as a single argument instead. But that's a small gain, I agree. Playback start on the other hand would have more benefits. pb_start_context(context: Item, ...) would allow just to pass an album, a track or a playlist without converting to URI first, which is currently needed. And certain combinations of arguments are not allowed, but having a separate method for contexts and tracks would ease that pain. Perhaps we should split the function first, then think about whether this model-based call is needed.

Having an examples directory sounds good. I've put it off for long enough.

[felix-hilden]

Anohter thing came to mind. Now the client and response models are clearly separated and models are used as arguments to client methods. But another kind of client could be created: one which returns objects that can interact with the web api themselves.

For example:

playlist = spotify.playlist(playlist_id)

# Current
spotify.playlist_change_details(name='New name!')
# vs new
playlist.change_details(name='New name!')

It would make vanilla token handling a bit difficult as the original client object could get "lost", even though accessible from the private members of the objects of course. And if you swap another user's token in the details change wouldn't work. But this could be a fun thing to try out sometime.

[felix-hilden]

I'll close this issue, as our new Discord server has a think thank for throwing around ideas.