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.
Oq: Terminal OpenAPI Spec Viewer
(github.com)94 points by der_gopher 11 hours ago | 12 comments
Comments
https://blacksmoke16.github.io/oq/ | https://github.com/Blacksmoke16/oq
(as I discovered when I installed oq via homebrew to find myself with a different app)
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)