I'm not really positive about the community made generator. The spec itself is great, but that's where it stops. Code quality is low of the generated clients and servers, the handlebars templates makes it hard to develop for and don't get me started about the PR reviews. Basically nothing happens. We've given up and started to create our own generator. Even this is a hard thing to do as the available parsers in our l…
>OpenAPI Generator allows generation of API client libraries from OpenAPI Specs It does, but the generated code can be very shitty for some combinations of spec and output language. I maintain Rust bindings for the Kubernetes API server's API, and I chose to write my own code generator instead. The README at https://github.com/Arnavion/k8s-openapi has more details. The point there about bugs in the spec is not limite…
The python libs are especially worthless. All functions are *kwargs and then the actual arguments are checked with code inside the body of the function. I once mad a stab at fixing it, but i got bored after getting feedback from my WIP PR that made it clear no one cared.
Have you taken a look at the v6.2.0 and onward 'python' client? It uses type hints, and model new instantiation includes required and optional property signatures. I am the author of that newer python generator.
I've found apenapi generated clients very helpful with statically typed languages and very unhelpful with dynamic languages. For dynamic languages I'd recommend using an http library directly. Consider the code without a generated client code: client.get("/hello") And the code with a generated client client.hello() In a dynamic language they're about the same. But in a statically typed language - I know the second ca…
The v6.2.0 python client uses type hints everywhere so model property access gives typed results
Endpoint inputs are typed. Endpoint responses are typed so you know what deserialized body models you are getting back. Have you tried it?