Skip to content

Incomplete OAS modeling #181

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
ghostbody opened this issue Jan 18, 2020 · 1 comment · Fixed by #193
Closed

Incomplete OAS modeling #181

ghostbody opened this issue Jan 18, 2020 · 1 comment · Fixed by #193

Comments

@ghostbody
Copy link

openapi-core is a great repo as I am going to write a schema parse based on OAS 3.0.2.

I some modeling work which is done in openapi_core/schema as well as openapi_core/extensions. But the modeling work is relatively incomplete to OAS 3.0.2 specification.

For example:

openapi_core/schema/infos/models.py

class Info(object):

    def __init__(self, title, version):
        self.title = title
        self.version = version

However, in OAS 3.0.2 Specification:

https://github.com/OAI/OpenAPI-Specification/blob/master/versions/3.0.0.md#infoObject

Field Name Type Description
title string REQUIRED. The title of the application.
description string A short description of the application. CommonMark syntax MAY be used for rich text representation.
termsOfService string A URL to the Terms of Service for the API. MUST be in the format of a URL.
contact Contact Object The contact information for the exposed API.
license License Object The license information for the exposed API.
version string REQUIRED. The version of the OpenAPI document (which is distinct from the OpenAPI Specification version or the API implementation version).

description, termsOfService, license, description fields are missing.

I think it's necessary to compelete thess model definitions. When I am implementing my parse for some integrated framework (i.e. sandman2), it's very hard to use a big dictionary to describe the api specification. I need something like a specification builder.

spec = Spec()
spec.info = Info(title='some title', description='some description', version='0.0.1')
spec.servers = [
  Server(url='some url', title='some title'),
  Server(url='some url2', title='some title2')
]

spec.components.define_schema(
    'some_schema',
    Schema(...)
)

spec.components.define_schema(
   'another_schema',
   some_parser.parse(some_model_may_be_sqlalchemy)    # A function that returns a Schema Object is better than a dict!
)

spec.paths.register_custom_path(...)   # some customized path regsiter as long as the fucntion returns a Path Model Object 

If you think this is a decent idea, I will be glad to help with PRs, as well as soem needed documentation work.

@p1c2u
Copy link
Collaborator

p1c2u commented Jan 21, 2020

Hi @ghostbody
it shouldn't be hard to add these fields. If you have spec dict you can use SpecFactory to parse it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants