Skip to content

Add support for OpenAPI 3 #2302

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

Merged
merged 5 commits into from
Dec 20, 2018
Merged

Conversation

antograssiot
Copy link
Contributor

@antograssiot antograssiot commented Nov 2, 2018

Q A
Bug fix? no
New feature? yes
BC breaks? no
Deprecations? no
Tests pass? yes
Fixed tickets
License MIT
Doc PR api-platform/docs#706

This PR aims to provide a way to export in a OpenAPI 3.0 compatible format.

This is still kind of a work in progress but I wanted to get early feedback on this.
Still tests and CS should be ok and good enough.
To ensure that the new normalizer is at least as tested as the v2, I've used the same tests and updated the expectations.

Here is some topics I'd like to discuss:

  1. I made the choice to create a separate documentation normalizer, here are the main reasons: ease v2 removal maybe at some point, do no interfere with Api Gateway normalizer, allow to be marked as experimental. I'm inclined to change this...

  2. This solution doesn't "transform" a swagger 2 compliant code to a version 3 compliant code. This implies that in the current situation, any overridden swagger context might not end up valid. Is it a big issue ?

Thank you before end for your time reviewing and discussing this.

TODO:

  • Check that the security parts of the generated files is ok
  • Add Links support
  • use query param to select version

$data = $this->documentationNormalizer->normalize($documentation);
$content = $input->getOption('yaml') ? Yaml::dump($data, 6, 4, Yaml::DUMP_OBJECT_AS_MAP | Yaml::DUMP_EMPTY_ARRAY_AS_SEQUENCE) : (json_encode($data, JSON_PRETTY_PRINT) ?: '');
$data = $this->$documentationNormalizer->normalize($documentation);
$content = $input->getOption('yaml') ? Yaml::dump($data, 10, 2, Yaml::DUMP_OBJECT_AS_MAP | Yaml::DUMP_EMPTY_ARRAY_AS_SEQUENCE) : (json_encode($data, JSON_PRETTY_PRINT) ?: '');
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I've increased the depth before inlining and reduced the indentation to 2 spaces as the latest version is even more nested


declare(strict_types=1);

namespace ApiPlatform\Core\Serializer;
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not sure if it belongs in this namespace

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Could be left in Swagger or added in OpenApi.

@antograssiot
Copy link
Contributor Author


declare(strict_types=1);

namespace ApiPlatform\Core\Serializer;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Could be left in Swagger or added in OpenApi.

@antograssiot antograssiot force-pushed the openapi-3 branch 2 times, most recently from cc7be75 to 8a7ec7d Compare November 3, 2018 09:45
<argument>%api_platform.collection.pagination.items_per_page_parameter_name%</argument>
<argument>%api_platform.collection.pagination.client_enabled%</argument>
<argument>%api_platform.collection.pagination.enabled_parameter_name%</argument>
<tag name="serializer.normalizer" priority="18" />
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@dunglas I think that this is requested so this normalizer became the default one too.
In understood from your comment in SwaggerCommand that you expect v3 to became the default, so I though it should change by default in swaggerUI too.

I can easily update all the behat swagger tests but I guess that you also expect this to still be tested (I would at least If some people still want to use v2) but I' don't know what would be the way to do that. it would need to change this priority in the test suite... ? or declare api_platform.openapi.normalizer.documentation as an alias of api_platform.swagger.normalizer.documentation ?
Anyway I don't really know if it is possible in a behat context and I wonder if setting this priority here is the good thing to do and if people expect SwagerUI to be updated automatically or if someone will want to stick to the old UI.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What do you think about allowing to choose the OpenAPI version through a query parameter? As done for API Gateway here: https://github.com/api-platform/core/blob/master/src/Documentation/Action/DocumentationAction.php#L66

Then it will be easy to test, and convenient for end users (they will be able to use OpenAPI v3 by default when supported, but still fallback to v2 for old tools).

For Swagger UI, we should to the same thing IMO (defaulting to v3, but allowing to switch to v2 by setting a query parameter).

WDYT?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

looks like a good idea, I'll try to update soon

@dunglas
Copy link
Member

dunglas commented Nov 5, 2018

@antograssiot do you think we can benefit from Links in this PR? It looks like a great new feature for API Platform.

@antograssiot
Copy link
Contributor Author

Yeah adding Link seems doable, I'll try to work on that

@antograssiot
Copy link
Contributor Author

@dunglas, I've ben working a bit more on this, not pushed yet and also waiting feedback on #2317 as it will be needed to... but I have a question on how should be handle the custom documentation.
Right now the swagger doc can be overridden using the swagger_context. As currently the OpenAPI normalizer doesn't transform a version 2 into a version 3, should I add the possibility to use a openapi_context attribute so people can override both documentation, should we keep using swagger_context only and then it's up to the developer to choose which version he want to support ?

@dunglas
Copy link
Member

dunglas commented Nov 11, 2018

Introducing an openapi_context looks indeed better to me

@antograssiot
Copy link
Contributor Author

@dunglas So I've rebased and put this branch up to date (implemented #2335 and #2344), I think that every tests should be passing, I'll re-read the whole PR tomorrow, I didn't took time to do this today but it should be ready for another set of review as discussed.

Copy link
Member

@dunglas dunglas left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can you rebase one more time please?

Copy link
Member

@meyerbaptiste meyerbaptiste left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The swagger.yaml file seems to be the result of the api:swagger:export command. IMO it could be removed.

Add a OpenAPI 3.0 compatible normalizer

Update the export command

Update AbstractDocumentation namespace

Increase new normalizer priority to make it the default in swaggerUI

Rename namespace from OpenApi to OpenAPI

Make OpenAPI 3 the default and alow to fallback to 2

Adding openapi_context attribute and cleaning
@dunglas dunglas merged commit aff44c9 into api-platform:master Dec 20, 2018
@dunglas dunglas changed the title [WIP] Add support for OpenAPI 3 Add support for OpenAPI 3 Dec 20, 2018
@antograssiot antograssiot deleted the openapi-3 branch December 20, 2018 19:56
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants