update to OpenAPI 3.1.x

[deanurce]

Im trying to upgrade to openapi 3.1.0 to be able to use type: mutualTLS in the security scheme definition, and it throws an error that the version is not recognised.
Since the 3.1.0 upgrade has been around for quite some time, will it be supported anytime soon?

Screenshot of error below.

[dbanty]

Actually supporting the features of 3.1.0 is probably a long way off since there are still 3.0 features incomplete 😬.

Reading the spec and just handling any breaking changes for the 3.0 features we do support is probably relatively easy, just a time investment.

I'm unlikely to have the time to do that anytime soon, but would welcome a PR from someone who does.

[staticdev]

For me this is an argument to also remove the validation for 3.1.0, since for 3.0.0 it works. We can have contributions when new features are needed but just because Fastapi started exporting it as 3.1.0 on latest versions shouldn't prevent us from using openapi-python-client altogether. This is now an issue for Fastapi users.

[staticdev]

Maybe consider #844

[philsturgeon]

The changes are not too major, just moving in line with JSON Schema for the schema objects and a few simplifications to examples. https://www.openapis.org/blog/2021/02/16/migrating-from-openapi-3-0-to-3-1-0

[johnthagen]

This is beginning to become much more important, as popular Python frameworks such as FastAPI, now generate only an OpenAPI 3.1.0 schema as of 0.99.0 released June 2023:

• https://fastapi.tiangolo.com/release-notes/#0990

[dbanty]

I'm trying to come up with a burndown list of things that need to be supported for OpenAPI 3.1.0. Anything that is a breaking change, we're going to have to deal with before we allow OpenAPI 3.1 documents and spit out tons of errors. Anything that is a feature, we can leave for later.

Must haves

I will accept a PR which allows 3.1.* documents if it also:

• Supports null as a primitive type, particularly in unions (oneOf, anyOf), since nullable is gone.
• Detects type arrays and explicitly prints a useful error message pointing at OpenAPI 3.1.0 Type Arrays #846, suggesting that the user vote for it or implement it via a PR. The default error message for this from Pydantic is pretty hard to read, so I don't want to get dozens of confused issues.
• Adds a copy of the end_to_end_tests openapi.json file which is updated for 3.1, and a test which verifies that it generates exactly the same code. If we add additional 3.1-specific features in the future, we can separate these, but for now we need to ensure that both syntaxes are supported. This is important because we can't test both the new and old nullability syntaxes in the same document without lots of tooling getting mad.

I think those are all the things required to support 3.1, and everything else can be treated as a new feature request in the future. Please comment here if there is something else that is required. I'd also love to see some testing of the eventual PR with real-world 3.1.0 servers if possible.

Non-goals

• We don't support all of 3.0.3, so we're not going to support all of 3.1.0.
• I have no interest in validating whether someone is using 3.1.0 correctly. If they provide some old 3.0.3 syntax that is technically invalid, as long as we understand the intent we can generate code. We're going to keep supporting 3.0.3 anyway, and separating the specs would be a lot of copy/pasting.

[staticdev]

@dbanty I tested #844 with a relatively large API app I have with Fastapi 0.99 (version that changes exported openapi to 3.1.0). It works! Any chance we merge it and have follow-up separate PRs to support these 3 features you mentioned?

[dbanty]

I tried this out for myself by making a very simple FastAPI server with a bit of nullability, because nullable should be broken with OpenAPI 3.1.0 documents. I thought maybe FastAPI is doing something sneaky and keeping around the old nullable syntax—but it is not. Here's the FastAPI code:

from fastapi import FastAPI

app = FastAPI()


@app.get("/hello/{name}")
async def say_hello(name: str | None) -> str | None:
    if name:
        return f"Hello {name}"
    return None

If I use the latest FastAPI (0.103.1), I cannot generate a client with openapi-python-client. It produces this document:

0.103.1 OpenAPI Document

{
  "openapi": "3.1.0",
  "info": {
    "title": "FastAPI",
    "version": "0.1.0"
  },
  "paths": {
    "/hello/{name}": {
      "get": {
        "summary": "Say Hello",
        "operationId": "say_hello_hello__name__get",
        "parameters": [
          {
            "name": "name",
            "in": "path",
            "required": true,
            "schema": {
              "anyOf": [
                {
                  "type": "string"
                },
                {
                  "type": "null"
                }
              ],
              "title": "Name"
            }
          }
        ],
        "responses": {
          "200": {
            "description": "Successful Response",
            "content": {
              "application/json": {
                "schema": {
                  "anyOf": [
                    {
                      "type": "string"
                    },
                    {
                      "type": "null"
                    }
                  ],
                  "title": "Response Say Hello Hello  Name  Get"
                }
              }
            }
          },
          "422": {
            "description": "Validation Error",
            "content": {
              "application/json": {
                "schema": {
                  "$ref": "#/components/schemas/HTTPValidationError"
                }
              }
            }
          }
        }
      }
    }
  },
  "components": {
    "schemas": {
      "HTTPValidationError": {
        "properties": {
          "detail": {
            "items": {
              "$ref": "#/components/schemas/ValidationError"
            },
            "type": "array",
            "title": "Detail"
          }
        },
        "type": "object",
        "title": "HTTPValidationError"
      },
      "ValidationError": {
        "properties": {
          "loc": {
            "items": {
              "anyOf": [
                {
                  "type": "string"
                },
                {
                  "type": "integer"
                }
              ]
            },
            "type": "array",
            "title": "Location"
          },
          "msg": {
            "type": "string",
            "title": "Message"
          },
          "type": {
            "type": "string",
            "title": "Error Type"
          }
        },
        "type": "object",
        "required": [
          "loc",
          "msg",
          "type"
        ],
        "title": "ValidationError"
      }
    }
  }
}

Which, interestingly, does not use the new type list feature, but it uses anyOf to add nullability. That causes these errors from the generator:

0.103.1 generator errors

Error(s) encountered while generating, client was not created

Failed to parse OpenAPI document

8 validation errors for OpenAPI
paths./hello/{name}.get.parameters.0.Parameter.schema.Reference.$ref
Field required [type=missing, input_value={'anyOf': [{'type': 'stri...ull'}], 'title': 'Name'}, input_type=dict]
For further information visit https://errors.pydantic.dev/2.1/v/missing
paths./hello/{name}.get.parameters.0.Parameter.schema.Schema.anyOf.1.Reference.$ref
Field required [type=missing, input_value={'type': 'null'}, input_type=dict]
For further information visit https://errors.pydantic.dev/2.1/v/missing
paths./hello/{name}.get.parameters.0.Parameter.schema.Schema.anyOf.1.Schema.type
Input should be 'string','number','integer','boolean','array' or 'object' [type=enum, input_value='null', input_type=str]
paths./hello/{name}.get.parameters.0.Reference.$ref
Field required [type=missing, input_value={'name': 'name', 'in': 'p...ll'}], 'title': 'Name'}}, input_type=dict]
For further information visit https://errors.pydantic.dev/2.1/v/missing
paths./hello/{name}.get.responses.200.Response.content.application/json.schema.Reference.$ref
Field required [type=missing, input_value={'anyOf': [{'type': 'stri...Hello Hello Name Get'}, input_type=dict]
For further information visit https://errors.pydantic.dev/2.1/v/missing
paths./hello/{name}.get.responses.200.Response.content.application/json.schema.Schema.anyOf.1.Reference.$ref
Field required [type=missing, input_value={'type': 'null'}, input_type=dict]
For further information visit https://errors.pydantic.dev/2.1/v/missing
paths./hello/{name}.get.responses.200.Response.content.application/json.schema.Schema.anyOf.1.Schema.type
Input should be 'string','number','integer','boolean','array' or 'object' [type=enum, input_value='null', input_type=str]
paths./hello/{name}.get.responses.200.Reference.$ref
Field required [type=missing, input_value={'description': 'Successf...lo Hello Name Get'}}}}, input_type=dict]
For further information visit https://errors.pydantic.dev/2.1/v/missing

Which are, in my opinion, definitely not readable. However, I then tried with 0.99, as you mentioned, and the generator did not complain. I checked out the document and it's this:

0.99 OpenAPI Document

{
  "openapi": "3.1.0",
  "info": {
    "title": "FastAPI",
    "version": "0.1.0"
  },
  "paths": {
    "/hello/{name}": {
      "get": {
        "summary": "Say Hello",
        "operationId": "say_hello_hello__name__get",
        "parameters": [
          {
            "required": true,
            "schema": {
              "type": "string",
              "title": "Name"
            },
            "name": "name",
            "in": "path"
          }
        ],
        "responses": {
          "200": {
            "description": "Successful Response",
            "content": {
              "application/json": {
                "schema": {
                  "type": "string",
                  "title": "Response Say Hello Hello  Name  Get"
                }
              }
            }
          },
          "422": {
            "description": "Validation Error",
            "content": {
              "application/json": {
                "schema": {
                  "$ref": "#/components/schemas/HTTPValidationError"
                }
              }
            }
          }
        }
      }
    }
  },
  "components": {
    "schemas": {
      "HTTPValidationError": {
        "properties": {
          "detail": {
            "items": {
              "$ref": "#/components/schemas/ValidationError"
            },
            "type": "array",
            "title": "Detail"
          }
        },
        "type": "object",
        "title": "HTTPValidationError"
      },
      "ValidationError": {
        "properties": {
          "loc": {
            "items": {
              "anyOf": [
                {
                  "type": "string"
                },
                {
                  "type": "integer"
                }
              ]
            },
            "type": "array",
            "title": "Location"
          },
          "msg": {
            "type": "string",
            "title": "Message"
          },
          "type": {
            "type": "string",
            "title": "Error Type"
          }
        },
        "type": "object",
        "required": [
          "loc",
          "msg",
          "type"
        ],
        "title": "ValidationError"
      }
    }
  }
}

The highlight is that it completely omits the concept of nullability—so it's inaccurate. The code generates, but you'll get exceptions at runtime any time a None is returned, which is (in my opinion) worse than the error messages.

Given that nullability is already one of the things people get wrong with OpenAPI most often (and open issues about when they're confused), I really want that to be fixed before we open up the floodgates. However, since FastAPI (the main source of OpenAPI documents in this ecosystem) isn't using type arrays, but instead is using anyOf, I will loosen my PR requirements to just accept "null" as a primative type anywhere it can be and do the right thing with type unions. (I'll update my above comment to clarify that). For the other pieces, as long as we can detect them and emit a single, useful error message (instead of the generic Pydantic ones) to reduce the amount of confusion, I think that we can push off implementing until someone opens a future PR for it.

[dbanty]

I should clarify, it seems to be the Pydantic v2 upgrade that adds back support for nullability using anyOf, since I ran 0.103 with Pydantic 1.0 and it gave me the null-less spec again.

[staticdev]

I see @dbanty then I think I will need some help to develop null type faster since I am not used to the code of this repo. Do you mind giving some guidance on where to chance?

[dbanty]

Hey all, #856 still needs some polish, but it should be functional enough to test. I would love it if folks would test it with their real schemas and make sure it works well (both 3.0 and 3.1).

[johnthagen]

Just for tracking purposes, another popular OpenAPI server (this one is for the Django ecosystem) recently added support for OpenAPI 3.1:

• OAS 3.1 tfranzel/drf-spectacular#825
• https://github.com/tfranzel/drf-spectacular/releases/tag/0.27.0

[dbanty]

Support added in 0.17!

[philsturgeon]

Contratulations! That's a huge milestone.

I've updated you on OpenAPI Tools, but can you add the appropriate GitHub tags so you'll show up properlty on https://tools.openapis.org/ (different thing).

• openapi2 (For Swagger/OpenAPI 2.0 support).
• openapi3 (For OpenAPI 3.0 support).
• openapi31 (For OpenAPI 3.1 support).

https://github.com/OAI/Tooling#how-can-you-help

[dbanty]

Thanks! I added those topics. It looks like, based on the description, this project should be under "SDK Generators" rather than "Converters", is that something you can fix as well?