As mentioned in https://github.com/p1c2u/openapi-schema-validator/pull/18 this is the extension for OpenAPI 3.1.

It is created as draft as it install jsonschema and openapi-schema-validator via GitHub in order to use the latest changes for Draft 2020-12.

The test cases provided in https://github.com/OAI/OpenAPI-Specification/tree/main/tests/v3.1 are used for the implementation.

Python 2.7 and 3.5 have been removed from the test matrix as they are end of life.

I'm open for sugestions if any changes are required in the PR.

In version 0.2.5 the PyYAML dependency was changed to PyYAML>=4.2b1. Since the latest non-beta version of PyYAML is 3.13, this means that dependency resolution fails if you do not allow beta packages.

Was this intentional? Looking at https://github.com/yaml/pyyaml/issues/193, the release story for PyYAML is a bit of a mess, but my understanding is that 3.13 was released to add Python 3.7 compatibility and the "should the load function be safe by default" issue will be resolved in an upcoming version 5.

I often miss the context provided by jsonschema library, so I'm trying to add it.

Given the following erroneous schema (it misses a description):

---
openapi: 3.0.0

info:
  title: test
  description: test
  version: 0.0.1

paths:
  "/":
    get:
      description: Get the API root
      responses:
        200:
          content:
            application/json:
              schema:
                type: string

without this PR, openapi-spec-validator displays:

{'content': {'application/json': {'schema': {'type': 'string'}}}} is not valid under any of the given schemas

Failed validating 'oneOf' in schema['properties']['paths']['patternProperties']['^\\/']['patternProperties']['^(get|put|post|delete|options|head|patch|trace)$'
]['properties']['responses']['patternProperties']['^[1-5](?:\\d{2}|XX)$']:
    {'oneOf': [{'$ref': '#/definitions/Response'},
               {'$ref': '#/definitions/Reference'}]}

On instance['paths']['/']['get']['responses']['200']:
    {'content': {'application/json': {'schema': {'type': 'string'}}}}

Basically telling « The path./.get.responses.200 is invalid: it should be a Response or a Reference. » without telling me about the missing description.

With this PR it gives:

{'content': {'application/json': {'schema': {'type': 'string'}}}} is not valid under any of the given schemas

Failed validating 'oneOf' in schema['properties']['paths']['patternProperties']['^\\/']['patternProperties']['^(get|put|post|delete|options|head|patch|trace)$']['properties']['responses']['patternProperties']['^[1-5](?:\\d{2}|XX)$']:
    {'oneOf': [{'$ref': '#/definitions/Response'},
               {'$ref': '#/definitions/Reference'}]}

On instance['paths']['/']['get']['responses']['200']:
    {'content': {'application/json': {'schema': {'type': 'string'}}}}


Due to those subschema errors:

'description' is a required property

Failed validating 'required' in schema[0]:
    {'additionalProperties': False,
     'patternProperties': {'^x-': {}},
     'properties': {'content': {'additionalProperties': {'$ref': '#/definitions/MediaType'},
                                'type': 'object'},
                    'description': {'type': 'string'},
                    'headers': {'additionalProperties': {'oneOf': [{'$ref': '#/definitions/Header'},
                                                                   {'$ref': '#/definitions/Reference'}]},
                                'type': 'object'},
                    'links': {'additionalProperties': {'oneOf': [{'$ref': '#/definitions/Link'},
                                                                 {'$ref': '#/definitions/Reference'}]},
                              'type': 'object'}},
     'required': ['description'],
     'type': 'object'}

On instance:
    {'content': {'application/json': {'schema': {'type': 'string'}}}}


'$ref' is a required property

Failed validating 'required' in schema[1]:
    {'patternProperties': {'^\\$ref$': {'format': 'uri-reference',
                                        'type': 'string'}},
     'required': ['$ref'],
     'type': 'object'}

On instance:
    {'content': {'application/json': {'schema': {'type': 'string'}}}}

This is probably a bit verbose, but I like a lot seeing 'description' is a required property.

I have a spec with components that look like this:

components:
  schemas:
    Credit:
      type: object
      properties:
        clientId:
          type: string
    CreditCreate:
      allOf:
        - $ref: '#/components/schemas/Credit'
        - required:
          - clientId

I'm doing it like this because there are about 30 fields in credit, and 10 in required. All the fields in required are present in the linked object (or objects if I'm linking more than one). This is rejected by the code in validators.py inside SchemaValidator. iter_errors calls itself recursively on each piece of the allOf, but this doesn't let me reuse another object and simply add some fields as required. I worked around it for now by telling iter_errors to check that the properties field contains something before erroring, but I'm not sure that it is the correct fix.

This behavior is supported in the swagger editor and in redoc, so I'm working off the assumption that it should be valid 3.0 syntax.

Hi, the jsonschema has been updated to 3.0+, and maybe has some break changes:

.eggs/openapi_spec_validator-0.2.4-py3.6.egg/openapi_spec_validator/__init__.py:7: in <module>
    from openapi_spec_validator.factories import JSONSpecValidatorFactory
.eggs/openapi_spec_validator-0.2.4-py3.6.egg/openapi_spec_validator/factories.py:5: in <module>
    from openapi_spec_validator.generators import (
.eggs/openapi_spec_validator-0.2.4-py3.6.egg/openapi_spec_validator/generators.py:12: in <module>
    class SpecValidatorsGeneratorFactory:
.eggs/openapi_spec_validator-0.2.4-py3.6.egg/openapi_spec_validator/generators.py:19: in SpecValidatorsGeneratorFactory
    'properties': _validators.properties_draft4,
E   AttributeError: module 'jsonschema._validators' has no attribute 'properties_draft4'

Hi, i've added a CLI interface for validating local files. For that i've created an entry_point in setup.py pointing to a new file openapi_spec_validator/__main__.py. After you installed the package with pip you are able to run

$ openapi_spec_validator path_to.yaml

to run a validation. This could also be extended to run tests on URLs, not just local files.

Dir structure:

├── fileA.yml
├── folderB
│   └── fileB.yml

From fileB.yml the validator does not permit usage of $ref: ../fileA.yml#/items/id . It works fine without the ../ in the beginning though.

This would allow the openapi spec v3 files to be rendered on the browser using swagger-ui tool.

When I try to install the package I get the following output.

Collecting openapi-spec-validator
  Could not find a version that satisfies the requirement openapi-spec-validator (from versions: )
No matching distribution found for openapi-spec-validator

When using a valid OpenAPI spec (validated also by the swagger editor) an error is returned on the responses validation.

$ python -m openapi_spec_validator ~/development/draft/api.yaml
{'description': 'Changed with success.', 'content': {'application/json': {'schema': {'$ref': '#/components/responses/GenericSuccess', 'x-scope': ['file:///development/draft/api.yaml']}}}} is not valid under any of the given schemas

Failed validating 'oneOf' in schema['properties']['paths']['patternProperties']['^/']['properties']['post']['properties']['responses']['patternProperties']['^([0-9X]{3})$']:
    {'oneOf': [{'$ref': '#/definitions/response'},
               {'$ref': '#/definitions/reference'}]}

On instance['paths']['/pets/{id}/comments']['post']['responses']['200']:
    {'content': {'application/json': {'schema': {'$ref': '#/components/responses/GenericSuccess',
                                                 'x-scope': ['file:///development/draft/api.yaml']}}},
     'description': 'Changed with success.'}

The spec looks like:

...
    put:
      summary: Comments.
      operationId: api.change
      requestBody:
        description: Something.
        required: true
        content:
          applicaton/json:
            schema:
              $ref: '#/components/schemas/CChange'
      responses:
        "200":
          description: Changed with success.
          content:
            application/json:
              schema:
                $ref: '#/components/responses/GenericSuccess'
...

This should not throw an exception. Because the API spec is valid as of https://github.com/OAI/OpenAPI-Specification/blob/master/versions/3.0.0.md#responseObject Unless I'm missing something here.

See the Fixed Fields section of the specs, towards the end:

A parameter MUST contain either a schema property, or a content property, but not both.

Adding the oneOf constraint requiring either content or schema fixes this issue.

The same issue applies to all objects that refer to Parameter Objects as their basis, such as e.g. Header Objects. I will add to this branch until I've adjusted all of those, and notify when this is done.

Fixes #130 Fixes #135

jsonschema released version 4.0.0 which dropped support for Python 2.7 and 3.5. openapi-spec-validator should do the same to support new versions of jsonschema. Both upstream dependencies and downstream dependents have already upgraded their jsonschema version constraints, which leads to conflicts with openapi-spec-validator.

When using the command python3.9 -m openapi_spec_validator example.yml where the example.yml file contains the following:

openapi: 3.0.0  
info:  
  title: Example OpenAPI  
  version: 0.0.1  
paths:  
  /mypath:  
    get:  
      parameters:  
        - name: myparam  
          in: query  
          schema:  
            format: date-time  
            type: string  
            example: 1997-07-16T19:20:30.45Z  
      responses:  
        '200':  
          description: Success  

The result is the error: Object of type datetime is not JSON serializable

If the example timestamp value in the YAML is wrapped in quotes, then the error does not occur and the result is: OK

This was observed with Python 3.9.16 and openapi-spec-validator 0.5.1. When using openapi-spec-validator 0.4.0, the error does not occur.

Bumps certifi from 2022.6.15 to 2022.12.7.

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

The following schema validation succeeded, even though the prop1 reference is broken.

openapi: 3.0.0
info:
  version: '1.0.0'
  title: 'Some Schema'
paths: {}
components:
  schemas:    
    SomeDataType:
      type: object
      properties:
        id:
          type: integer
        prop1:
          $ref: '<some-broken-uri>'
        prop2:
          type: string

It seems like this commit https://github.com/p1c2u/openapi-spec-validator/commit/03d4937a85482bed16e0e92bf6795b8778458227 breaks https://github.com/p1c2u/openapi-core (v0.14.2). Our imports are failing now.

First of all, I'm focussing on validating models (components/schemas) in an OpenAPI 3.0.0. yaml file.
I'm testing with a slightly changed petstore.yaml (keep an eye on components/schemas/Pet/properties/id which has an extra attribute min instead of minimal):

openapi: "3.0.0"
info:
  version: 1.0.0
  title: Swagger Petstore
  license:
    name: MIT
servers:
  - url: http://petstore.swagger.io/v1
paths:
  /pets:
    get:
      summary: List all pets
      operationId: listPets
      tags:
        - pets
      parameters:
        - name: limit
          in: query
          description: How many items to return at one time (max 100)
          required: false
          schema:
            type: integer
            format: int32
      responses:
        200:
          description: An paged array of pets
          headers:
            x-next:
              description: A link to the next page of responses
              schema:
                type: string
          content:
            application/json:    
              schema:
                $ref: "#/components/schemas/Pets"
        default:
          description: unexpected error
          content:
            application/json:
              schema:
                $ref: "#/components/schemas/Error"
    post:
      summary: Create a pet
      operationId: createPets
      tags:
        - pets
      responses:
        '201':
          description: Null response
        default:
          description: unexpected error
          content:
            application/json:
              schema:
                $ref: "#/components/schemas/Error"
  /pets/{petId}:
    get:
      summary: Info for a specific pet
      operationId: showPetById
      tags:
        - pets
      parameters:
        - name: petId
          in: path
          required: true
          description: The id of the pet to retrieve
          schema:
            type: string
      responses:
        '200':
          description: Expected response to a valid request
          content:
            application/json:
              schema:
                $ref: "#/components/schemas/Pets"
        default:
          description: unexpected error
          content:
            application/json:
              schema:
                $ref: "#/components/schemas/Error"
components:
  schemas:
    Pet:
      required:
        - id
        - name
      properties:
        id:
          min: 1
          type: integer
          format: int64
        name:
          type: string
        tag:
          type: string
        $ref:
          type: string
    Pets:
      type: array
      items:
        $ref: "#/components/schemas/Pet"
    Error:
      required:
        - code
        - message
      properties:
        code:
          type: integer
          format: int32
        message:
          type: string

Swagger Editor reports nicely on that little "typo" in pet's property id:

No matter what I try with openapi-spec-validator, it reqognizes an error like that from above but the error (OpenAPIValidationError or iterator) is totally unspecific.

Validating the above yaml with:

  try:
      spec_dict, spec_url = read_from_filename('model.yaml')
      validate_v30_spec(spec_dict)
  except IOError as e:
      print(e)
  except OpenAPIValidationError as e:
      print(e)

...gives an output like:

{'description': 'An paged array of pets', 'headers': {'x-next': {'description': 'A link to the next page of responses', 'schema': {'type': 'string'}}}, 'content': {'application/json': {'schema': {'$ref': '#/components/schemas/Pets', 'x-scope': ['']}}}} is not valid under any of the given schemas

Failed validating 'oneOf' in schema['properties']['paths']['patternProperties']['^\\/']['patternProperties']['^(get|put|post|delete|options|head|patch|trace)$']['properties']['responses']['patternProperties']['^[1-5](?:\\d{2}|XX)$']:
    {'oneOf': [{'$ref': '#/definitions/Response'},
               {'$ref': '#/definitions/Reference'}]}

On instance['paths']['/pets']['get']['responses']['200']:
    {'content': {'application/json': {'schema': {'$ref': '#/components/schemas/Pets',
                                                 'x-scope': ['']}}},
     'description': 'An paged array of pets',
     'headers': {'x-next': {'description': 'A link to the next page of '
                                           'responses',
                            'schema': {'type': 'string'}}}}

No hint on that specific error ("additionalProperty in pet.id" or something like that).

Is openapi-spec-validator not what I'm looking for? Do I use this validator in a wrong way? Do I miss anything?