#/components/schemas across routes

[EnriqueL8]

I have a set of routes that share a child schema such as one API returns an array of objects and another API returns one object. The object itself has the same schema but when I generate the OpenAPI I get duplicate values for that schema and do not get the schema stored under #/components/schemas. I might be doing something wrong here... so any insights appreciated 😄

I'm using NewSchemaRefForValue for each return object from my API. It will get called either with the array of objects or the objects. With the schema ref it returns I will append it to the document I'm constructing.

I see that for a new schema do be added to #/components/schemas it needs to be a cyclical dependency? But as far as I can see that only happens in the context of that specific schema as it checks for parents. How do I provide other schemas in the OpenAPI that I have parsed?

Thanks in advance!

[sskserk]

Hi @EnriqueL8, @fenollp,

First of all thank you for a good project, it really helped a lot!

I also face the same obstacle (not a problem). Is it possible anyhow to generate a ref for a nested object? Right now it is only generated if there is recursion. Schemes for complex objects generated as nested sub-properties:

Example:

User:
      properties:
        attributesMapping:
          properties:
            email:
              type: string
            login:
              type: string
            name:
              type: string
            secondName:
              type: string
          type: object
        name:
          type: string
        lastName:
          type: string
      type: object

@fenollp Is it possible instead to generate two schemes and refer one from another?

Thank you!

P/S: I'm ready to bring a MR if you point where it can be fixed.

[sskserk]

@fenollp what do you think on the current problem? Thanks!

[EnriqueL8]

@sskserk I raised a draft PR #914 and will add more validation and see what the maintainers think!

[fenollp]

Hi! I welcome such changes.
My only requirement is that it's tested and the new option behaves well with the others (and their combinations).

So yeah, please work together on that PR and once you both are satisfied I'll help you merge it.