kin-openapi is not compatible with go-openapi/jsonpointer

[gordallott]

I realize this may be a bit of an esoteric issue, but right now, openapi3 structures are not compatible with github.com/go-openapi/jsonpointer. Functionally that means that you can't take a jsonpointer reference + an openapi3.Swagger and get reliably get a valid result.

The crux of the problem is the *Ref values. Using the petstore example and trying to get /paths/~1pet/put/responses/200/content fails as /paths/~1pet/put/responses/200 resolves to a ResponseRef value which doesn't have a content field

One approach would be by adding JSONLookup functions to all the ref structures, but the nieve approach (as outlined in how go-openapi deals with similar situations) introduces a dependency on github.com/go-openapi/jsonpointer which I'm not sure would be wanted

In addition to play nice with jsonpointer references, something like /components/schemas/Foobar should return a *Schema or struct{Ref string} depending on if Foobar is a Schema Object or a Request Object. Which would require a bunch of additional types like Schemas Headers Parameters and so on

I'm almost certainly going to need to solve this problem myself, but if I did so in a way that was upstreamable that would be a bonus

[fenollp]

Hi Gordon,
Looks like the JSONLookup way is the more sensible.
Do you have a working example / some tests that show what you'd want?
Thanks

[gordallott]

Hi,

Yeah I have a working branch here axiomhq@7cf71ff

but it's currently depending on go-openapi/jsonpointer#5 getting merged, which whilst approved by someone hasn't been merged yet

It's a little more invasive than I would have liked given that I had to introduce a Ref type and change some untyped fields into typed fields to add JSONLookup methods, but it works quite successfully, we are using my branches internally without any problems

If the above pull request ever gets merged I'll probably submit one back into kin-openapi, but until it does there isn't much point