Chat with us about libopenapi

[daveshanley]

Howdy partners!

Do you have a question about libopenapi and you don't want to jump on our Discord Server to ask us live?

No problem!

Ask us here.

[nickajacks1]

@daveshanley Are there plans to further support AsyncAPI? Based on the name of the project I would assume the answer is "no", but I do see that there is a small amount of explicit support for AsyncAPI.
Maybe the demand just isn't there, but I'd love to see a way to validate websocket payloads against an AsyncAPI spec the same way I validate regular HTTP payloads against an OpenAPI spec.

[daveshanley]

Yep. 100%

In fact, I actually started with AsyncAPI, all of the pb33f stack runs primarily over pub/sub, the entire architecture is message based. In fact if you open up your dev tools and go to https://pb33f.io/openapi-changes/demo/ you will see a websocket is opened, and all the APIs for the openapi-changes UI run over STOMP and pub/sub via websocket.

The reason why I've focused on OpenAPI for now, is because the ecosystem is bad and there is so little choice for good tooling alternatives. However, my main goal has always been AsyncAPI. It's because that's where the future of application design lies in my opinion.

So, long story short, I would have skipped all the OpenAPI tools (which I need desperately) if the ecosystem was better. Once we get to a 1.x release on libopenapi it will be time to build libasyncapi

[vanntile]

Is there a way envisioned to turn the OpenAPI schemas into go structures and, after validating the HTTP Requests, to get the response bodies as those struct values? If one is validating the request bodies, it would be quite helpful to unmarshal those bodies too.

[nickajacks1]

One of the challenges here is that it's not always clear what your data is going to be marshalled into when allOf, anyOf, oneOf, or not are used.
Some ways to potentially simplify this are to use a discriminator or extensions (eg an extension whose value is a custom unmarshal function to use for that schema)

Indeed, validating against a schema only to later have to do duplicate checks to see what struct the payload should be unmarshalled into is wasteful.

[daveshanley]

It may be worth looking at https://www.speakeasyapi.dev/ to generate go structs. I don't personally plan on building in that capability to the library, as it's designed to be used downstream by tools to do things like generate structs, docs, bindings, SDKs etc.