Chore: Audiobookshelf - adapt schema to reflect the naming scheme used in the API docs

[fmunkes]

This PR adapts classes defined in abs_schema.py to use the same names (+ prefix ABS) as in the API doc of Audiobookshelf. Many items have multiple variants, e.g. a Book exists in a minified, expanded and normal version. Now, classes are named accordingly:

• ABSBook
• ABSBookMinified
• ABSBookExpanded

I've been rather loose in the initial version, however, I believe this makes future maintenance and possible enhancements much easier. There is no logical code change in this PR.

[fmunkes]

that was bad luck - abs got updated to 2.18.0, and they changed some structure apparently. audiobooks appear to befine, podcasts not. I'm looking into this right now

[marcelveldt]

LGTM

[marcelveldt]

that was bad luck - abs got updated to 2.18.0, and they changed some structure apparently. audiobooks appear to befine, podcasts not. I'm looking into this right now

Ah saw this too late - lets hold off merging then. Please mark as ready when its ready again

[fmunkes]

Found it. Sorry about that. Just updated the abs container, and then noticed the issue. It appears to be fine again, was just a minor issue.
@OzGav would you please add something like this to the documentation:
"This provider is always tested against the latest containerized non-development version of Audiobookshelf, i.e. ghcr.io/advplyr/audiobookshelf:latest"

[Jc2k]

Doesn't block this but would be good to add some tests for the schemas and the parse* functions in the provider - you can see how we do that in here: #1859. We are doing snapshot testing, and take a directory of sample JSON data from the target service and verify it against a snapshot of our music_assistant_models like Track, Album, etc.

(If you had those tests know, then you'd be able to refactor the schemas and know that you hadn't broken the Music Assistant models that are created in your parse* functions).

I can help with that, but I don't have any sample data on my end.

[fmunkes]

Doesn't block this but would be good to add some tests for the schemas and the parse* functions in the provider - you can see how we do that in here: #1859. We are doing snapshot testing, and take a directory of sample JSON data from the target service and verify it against a snapshot of our music_assistant_models like Track, Album, etc.

(If you had those tests know, then you'd be able to refactor the schemas and know that you hadn't broken the Music Assistant models that are created in your parse* functions).

I can help with that, but I don't have any sample data on my end.

That indeed sounds like a very good idea, thanks for offering your help!
I will look into it, though I will need some more time than I have on this weeks workdays, as this is completely new to me. I will invest some time this weekend to read up/ setup my environment for it, and would also create a test instance of abs, such that I can generate some useful json responses for e.g. an audiobook with very little/ a lot of metadata etc. Currently it's just tested against my normal instance.
When I have all this, I'd create a draft PR, where we can discuss how far I got. Is that ok with you?

[Jc2k]

That sounds great!