A couple of enhancements

[rafalkrupinski]

Some enhancements I'd be happy port from my project:

• parametrized Reference (Request: Add type parameter to Reference #39)
• ExtendableModel (Better support of Specification Extensions for callbacks, paths and responses #40, also validate extended properties start with 'x-' in 3.0)
• parameter style enum (currently it's str)
• validating that no more than one of example and examples is defined
• ModelWithAdditionalProperties (I use it for operations in PathItem, instead of separate fields)
• ModelWithPatternProperties (paths must start with '/', response keys constrained with regex)
• reference resolver (local only)
• exposing ParameterBase (parent of Parameter and Header)

Also, Paths could be changed to dict[str, PathItem | Reference], and ref could be removed from PathItem. this is valid

• validate parameter has no more than one of content and schema

[rafalkrupinski]

@mike-oakley

[mike-oakley]

Hey @rafalkrupinski - apologies for my slow reply here! Commented on the other issues too, but in general i'm happy to accept contributions if its enhancing/within the spirit of openapi/pydantic and maintains support for oas 3.0.x and pydantic 1 + 2.

The only one I'm not sure of in the above is the ref resolver, not sure if it would bloat the surface area of the project too much to be opinionated on it, as we try to defer to Pydantic for most of the heavy lifting on the JSONSchema side. Happy to hear a suggestion if you can suggest an elegant enough API for it 👍🏼

[rafalkrupinski]

Resolving references is actually quite simple.

• decode and split path
• resolve path element in dict or by alias in BaseModel
• traverse objects starting from OpenAPI instance
• apply recursively until result is not a Reference itself
• keep list of resolved json paths to avoid infinite recursion

It could be a method in OpenAPI and a couple of helper functions.
I have the code already in my project, I'll prepare a PR.

[rafalkrupinski]

@mike-oakley you don't think running mypy on tests is an overkill?

[kgpayne]

+1 for a reference resolver. I am trying to extract a complete schema from a given path-method-response, and was surprised to find refs aren't currently auto-resolved. Especially given the reverse case is true; refs are added to generated json/yaml spec outputs, at least when using the construct_open_api_with_schema_class utility function as per the README. Adding a resolver utility would help, even if it isn't used in the default behavior of parse 🙂