Client code generation about yetanotherhueapi HOT 2 OPEN

Hey, thanks for reaching out and sharing about the project, Thibault! 😃 I can definitely see how that would be complementary to Yet Another Hue API. I'm not sure, however, if it's a bit late at this point, now that the most important parts of the new Hue API have already been implemented... Also, in the past I've had bad experiences trying to generate good code from any non-trivial OpenAPI spec, but I attribute that to the generators.

I would, one day, should I find to much extra time in my hands, love to have a go at creating a code generator myself, though: I'd like a generator that would just make me the DTOs as clean, Jackson-annotated classes. Like, leave the network traffic part out of it, allowing people to use Spring or plain Jackson or some other compatible framework. Possibly even leaving out the Jackson annotations so one could use other deserialization libraries too... 🤔

But at least the openhue-api will become really useful when debugging and trying to understand the API! I can see myself loading it to Postman, for example -- I admit so far I've only used the rather dreadful /clip/v2/ service that the Bridge providers via a browser form... 🙈

So anyway thank you again for reaching out and let me know if you have any further ideas or comments!

from yetanotherhueapi.

now that the most important parts of the new Hue API have already been implemented

Absolutely no worries! I understand that you are almost ready to release the v3 version of your library that now relies on the Hue Clip V2 API, very well done for that 👏

I'd like a generator that would just make me the DTOs as clean, Jackson-annotated classes.

This would be definitely possible using the OpenAPI Generator Maven Plugin, that has an option to generate the models only (cf. generateModels). Then it would also be possible to override the default code generation templates so that they don't generate code with Jackson dependencies.

I actually started the spec to develop the openhue-cli project, where I generate the Go client-side code. This actually helps me verify if the spec is valid or not.

But at least the openhue-api will become really useful when debugging and trying to understand the API!

That's indeed one the main goal of the openhue-api! I made a short YouTube video explaining how to load the spec inside Postman. You can also easily browse the spec from the Swagger Editor.

Each new release of the spec is automatically deployed and accessible via this URL.

from yetanotherhueapi.