From 24cf97c032e4220cb70ad522195acca294789c14 Mon Sep 17 00:00:00 2001 From: Xoconoch <93692082+Xoconoch@users.noreply.github.com> Date: Wed, 11 Jun 2025 11:52:41 -0600 Subject: [PATCH] Update callback_examples.md --- docs/callback_examples.md | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/docs/callback_examples.md b/docs/callback_examples.md index ebacfa5..ac86051 100644 --- a/docs/callback_examples.md +++ b/docs/callback_examples.md @@ -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/`. +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 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."