Skip to content

OpenAPI 3.0 should generate and reference #/components/schemas/ #6984

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
1 task
partimer opened this issue Oct 10, 2019 · 7 comments · Fixed by #7124
Closed
1 task

OpenAPI 3.0 should generate and reference #/components/schemas/ #6984

partimer opened this issue Oct 10, 2019 · 7 comments · Fixed by #7124

Comments

@partimer
Copy link

Checklist

  • [X ] I have verified that that issue exists against the master branch of Django REST framework.
  • [X ] I have searched for similar issues in both open and closed tickets and cannot find a duplicate.
  • [X ] This is not a usage question. (Those should be directed to the discussion group instead.)
  • [X ] This cannot be dealt with as a third party library. (We prefer new functionality to be in the form of third party libraries where possible.)
  • [ X] I have reduced the issue to the simplest possible case.
  • I have included a failing test as a pull request. (If you are unable to do so we can still accept the issue.)

Steps to reproduce

Swagger 2.0 supports the concept of a definition #/definitions/{ModelName}. This is superseded in OpenAPI 3.0 with #/components/schemas/{ModelName}

Expected behavior

  1. OpenAPI 3.0 output should contain #/components/schemas/{ModelName}
  2. Each schemas should minimally contain the same type of information found in Swagger 2.0 definitions.
  3. Optionally, #/paths/... can reference #/components/schemas/{ModelName} rather than a full definition
  4. #/components/schemas/{ModelName} should include "title" and format="uri"

Actual behavior

  1. #/components/schemas is not generated.
  2. Information has to be scoured from the #/paths/...
  3. Some Information found in Swagger 2.0 definitions such as string format information is not present in any equivalent form.
  4. Information in i.e. #/paths.../properties/schemas is often duplicated (bigger schema file)
@partimer partimer changed the title OpenAPI 3.0 generate #/components/schemas/ OpenAPI 3.0 should generate and reference #/components/schemas/ Oct 10, 2019
@carltongibson
Copy link
Collaborator

Yes. This would be a great a addition. A super contributing opportunity!

@partimer
Copy link
Author

Is the following considered a supported DRF use case?
Use Case: Javascript client using drf-yasg generated Swagger 2.0, utilizing #/definitions to define client side object, migrates to drf generated OpenAPI3.0.

@carltongibson
Copy link
Collaborator

Not "supported" no. 🙂 We'd need logic to go from serializers/models to component definitions, and then operations would need to reference those.

@n2ygk
Copy link
Contributor

n2ygk commented Oct 11, 2019

I started implementing this over here: django-json-api/django-rest-framework-json-api#689. I've been sort of on hold with this, with feedback being some of the stuff I did would best be implemented upstream here. However, I've been busy with other stuff at work lately. Feel free to use anything useful you see there. Most of the relevant code is in openapi.py

@carltongibson
Copy link
Collaborator

Super. Good stuff @n2ygk! Thanks for your efforts.

@bo0tzz
Copy link

bo0tzz commented Nov 20, 2019

I'd love to have this feature. @n2ygk you mentioned that you were working on an implementation for this over in another project. Do you have an idea of the efforts needed to get that code back into drf? Hopefully I'd be able to dedicate some time to this.

@gnuletik
Copy link
Contributor

gnuletik commented Jan 8, 2020

I just made a PR for this issue. It's working without issue on our large codebase. Feel free to give it a try ;)

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.

5 participants