Nice, I'll find this useful. I reference OpenAPI specs frequently as I practice spec-driven development. The spec is my source of truth for the interface, and I use it to generate both my client and server code. It automates all the request handling boilerplate on both sides, including validation, and provides me a typed interface regardless of which language I'm using. OpenAPI of course limits the types of endpoints you can create, but I find those limits stop you doing things that are strange/surprising. I find that creating APIs that can be expressed nicely in OpenAPI leads to APIs that have a consistent feel with few gotchas and a satisfyingly predictable developer experience.
Ooh interesting!
I see it notes OpenAPI 3.1 support, but it's using kin-openapi which doesn't yet support OpenAPI - how have you managed that?
(speaking as someone building on top of kin-openapi, as a core maintainer for oapi-codegen)
Nice, I'll find this useful. I reference OpenAPI specs frequently as I practice spec-driven development. The spec is my source of truth for the interface, and I use it to generate both my client and server code. It automates all the request handling boilerplate on both sides, including validation, and provides me a typed interface regardless of which language I'm using. OpenAPI of course limits the types of endpoints you can create, but I find those limits stop you doing things that are strange/surprising. I find that creating APIs that can be expressed nicely in OpenAPI leads to APIs that have a consistent feel with few gotchas and a satisfyingly predictable developer experience.
100%, also openapi specs are usually huge yaml/json files and it's very hard to navigate them.
Really cool! would be cool to be able to do the actual call too :)
I believe it will come to that too.
Love this.