-
-
Notifications
You must be signed in to change notification settings - Fork 922
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
Conversation
124c6b2
to
2cfb0a3
Compare
$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) ?: ''); |
There was a problem hiding this comment.
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; |
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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
.
2cfb0a3
to
be078cd
Compare
|
||
declare(strict_types=1); | ||
|
||
namespace ApiPlatform\Core\Serializer; |
There was a problem hiding this comment.
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
.
cc7be75
to
8a7ec7d
Compare
<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" /> |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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
@antograssiot do you think we can benefit from Links in this PR? It looks like a great new feature for API Platform. |
Yeah adding Link seems doable, I'll try to work on that |
@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. |
Introducing an |
d3e434d
to
e230116
Compare
e230116
to
d6ddfc6
Compare
There was a problem hiding this 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?
There was a problem hiding this 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
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:
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...
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: