JDM170/deezspot-spotizerr-dev
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Update callback_examples.md

Browse Source
This commit is contained in:
Xoconoch
2025-06-11 11:52:41 -06:00
committed by GitHub
parent 41bfff7ce9
commit 24cf97c032
1 changed files with 4 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files

4
docs/callback_examples.md
View File

@@ -2,6 +2,10 @@
This document provides examples for all possible callback JSON objects as generated by `deezspot`. These examples are based on the dataclasses defined in `deezspot/models/callback/`. This document provides examples for all possible callback JSON objects as generated by `deezspot`. These examples are based on the dataclasses defined in `deezspot/models/callback/`.
These callbacks are service-agnostic, which means they will have the same exact format regardless of the service used. Basically: one interface to rule them both.
However, don't be so confident this will perfectly unify both service's APIs, since there are still key differences in the metadata itself, for example: in spotify, certain band shows up as [Man**á**](https://open.spotify.com/artist/7okwEbXzyT2VffBmyQBWLz) but in deezer it shows up as [Man**a**](https://www.deezer.com/us/artist/4115). There's really nothing to be done in those cases other than deal with it, since the inconsistency is not a matter of _how_ the services store their data but literally _what_ data they store.
## Naming Convention ## Naming Convention
The data models in `deezspot/models/callback/` follow a specific naming convention to clarify the context of nested objects. The pattern is generally `childContext1Context2...Object`. This reads as "A `child` object representation when nested inside a `Context1` object, which itself is in a `Context2` context, and so on." The data models in `deezspot/models/callback/` follow a specific naming convention to clarify the context of nested objects. The pattern is generally `childContext1Context2...Object`. This reads as "A `child` object representation when nested inside a `Context1` object, which itself is in a `Context2` context, and so on."