Query parameters array "serialization" strategy

[ClementMindflow]

Some AWS services like CloudFormation allow to pass array of values as query parameters.

Exemple of this, the StackStatusFilter of the ListStacks action in CloudFormation api.

When "serializing" this array to form the final url, the AWS docs state that each individual item should be stored as following:

...&StackStatusFilter.member.1=CREATE_IN_PROGRESS&StackStatusFilter.member.2=DELETE_COMPLETE&...

The Open API 3.0 does not mention that "style" of serialization.

Do you know a workaround to have the generated OpenAPI work with such serialization scheme ?

Thanks

[MikeRalphson]

Unfortunately not, though we could add a specification extension to mark it if you are using your own tools to post process?

[ClementMindflow]

That would be awesome !

As of now we are manually patching the schema to tag the appropriate field with an awsMember flag to handle them the right way.

If you explain me to run the aws2openapi against the source aws schema, i could patch it.

By the way: Where are located the source aws schema ( i guess in smithy format ) ?

[MikeRalphson]

Apologies for the lack of proper docs. If you checkout https://github.com/aws/aws-sdk-js in a sibling directory to a checkout of aws2openapi (in the latter where you have run npm i) running node aws2openapi should process all the smithy (or smithy-like?) files in https://github.com/aws/aws-sdk-js/tree/master/apis to the ./aws/ directory.

[ClementMindflow]

Awesome thanks !
One other question:
Why don't you use the software.amazon.smithy:smithy-openapi plugin for the Smithy Gradle plugin provided by smithy to generate the OpenAPI ?

[MikeRalphson]

Why don't you use the software.amazon.smithy:smithy-openapi plugin for the Smithy Gradle plugin provided by smithy to generate the OpenAPI ?

I don't think that package was available/open-source when aws2openapi was created. Also I'm not a Java developer, so I don't use or have any experience with Gradle.

The openapi plugin is highly configurable to support different OpenAPI tools and vendors.

We try and create a generic best-case OpenAPI definition, we would have to be opinionated about what plugin options we set.