EbbLabs/python-tidal

Align type definitions with OpenAPI spec

Opened this issue · 1 comments

There are a couple of fields whose types I'm not sure about.

For example, various album fields like name, explicit etc are defined to be optional:

id: Optional[int] = -1
name: Optional[str] = None
cover = None
video_cover = None
type = None
duration: Optional[int] = -1
available: Optional[bool] = False
ad_supported_ready: Optional[bool] = False
dj_ready: Optional[bool] = False
allow_streaming: Optional[bool] = False
premium_streaming_only: Optional[bool] = False
num_tracks: Optional[int] = -1
num_videos: Optional[int] = -1
num_volumes: Optional[int] = -1
tidal_release_date: Optional[datetime] = None
release_date: Optional[datetime] = None
copyright = None
upc = None
version = None
explicit: Optional[bool] = True
universal_product_number: Optional[int] = -1
popularity: Optional[int] = -1
user_date_added: Optional[datetime] = None
audio_quality: Optional[str] = ""
audio_modes: Optional[List[str]] = [""]
media_metadata_tags: Optional[List[str]] = [""]

But in the Tidal OpenAPI spec they are required:

curl https://tidal-music.github.io/tidal-api-reference/tidal-api-oas.json | jq .components.schemas.Albums_Attributes.required
[
  "barcodeId",
  "duration",
  "explicit",
  "mediaTags",
  "numberOfItems",
  "numberOfVolumes",
  "popularity",
  "title",
  "type"
]

IDs are also required just based on the JSON:API spec.

Are you happy with a PR to align these types with the OpenAPI spec?

FYI tidalapi is developed by reverse engineering the closed API and is therefore not directly corresponding with the OpenAPI.

So before making such changes, it is necessary to make sure the closed API and OpenAPI endpoints actually use the same type definitions. It's likely that they follow a similar spec, but it would need to be verified by making experiments IMO.

PRs are of course very welcome 👍