Feature request: Support for oneOf, anyOf, and allOf keywords in OpenAPI specs

[LuukBosch]

Feature

Support oneOf, anyOf, and allOf in OpenAPI specifications

Why and what

Reynard currently doesn't build objects for schemas using oneOf, anyOf, or allOf keywords, which are common in OpenAPI 3.0 specifications for polymorphic types and schema composition. This forces developers to work with raw hash data instead of proper model objects.

It would be nice if Reynard automatically detect these keywords in schemas, resolve which variant match the response data, and build the appropriate Ruby model objects just like it does for regular object and array types.

[Manfred]

I've been working on branch to have more control over response encoding and models so I will take a peek if I can incorporate this.

[Manfred]

@LuukBosch it would be nice if you get a chance at some point to give 0.10.2 a try.

[LuukBosch]

Thanks @Manfred! I had a look at 0.10.2.

For our use case it doesn't quite help yet. Our schemas already have explicit type: object alongside allOf, so the type inference doesn't come into play. The top-level model was already being created fine.

The issue we're hitting is that property_schema only looks at [*node, 'properties', name], so it can't find properties that are defined through allOf entries. This means nested objects stay as raw Hashes instead of becoming models.
For example, with a schema like:

Pet:
  type: object
  allOf:
    - $ref: "#/components/schemas/Animal"
    - type: object
      properties:
        owner:
          type: string

Animal:
  type: object
  properties:
    name:
      type: string
    collar:
      type: object
      properties:
        color:
          type: string

response.object.name works , but response.object.collar returns {"color" => "red"} instead of a model, because property_schema doesn't look inside allOf to find it. Its not a blocker for us at the moment btw.

[Manfred]

Ah right, this is one of the downsides of operating directly on the specification structure. Ideally we would we would dereference and merge the schemas of the objects using allOf, but that could potentially take additional memory when the reference is repeated in a lot of objects. We might be able to use Ruby modules as sort-of compiled units.