apis-guru / aws2openapi Goto Github PK

View Code? Open in Web Editor NEW

53.0 5.0 10.0 225 KB

Amazon Web Services API description to OpenAPI 3.0 definition

Home Page: https://github.com/APIs-guru/openapi-directory/tree/master/APIs/amazonaws.com

License: MIT License

JavaScript 98.65% Shell 1.35%

openapi swagger aws amazon amazon-web-services amazon-s3-storage amazon-api openapi3

aws2openapi's Introduction

aws2openapi

Amazon Web Services API description to OpenAPI 3.0 specification

Work in progress - beta quality

Handles all current (v2) AWS json and xml specifications

Resultant OpenApi specifications pass multiple validators

The results of this converter can be found here

TODO help wanted

~~Fix input header parameter selectivity~~
~~Process protocol:ec2~~
~~Authentication~~ You will have to calculate HMAC headers manually
~~pagination~~
~~Examples~~
~~Waiters~~ (as vendor extension)
Test against live endpoints
Verify output header mappings
Test path-with-fragment hack works
Test paths with hardcoded ?parameters work
Validate xml-handling keyword translations

aws2openapi's People

Contributors

Stargazers

Watchers

Forkers

pilgrim2go rbren mterrel pimterry pjbrito ivy-rew ikanni septianw lmmx sjesinc

aws2openapi's Issues

Duplicate Operation Paging Parameters in S3

I think this is the same issue you had with EC2.
For example the following operation:

    "operationId": "ListMultipartUploads",
    "description": "This operation lists in-progress multipart uploads.",
    "externalDocs": {
      "url": "http://docs.amazonwebservices.com/AmazonS3/latest/API/mpUploadListMPUpload.html"
    },
    "responses": {
      "200": {
        "description": "Success",
        "schema": {
          "$ref": "#/definitions/ListMultipartUploadsOutput"
        }
      }
    },
    "parameters": [
      {
        "name": "Bucket",
        "in": "path",
        "required": true,
        "description": "<p/>",
        "type": "string"
      },
      {
        "name": "delimiter",
        "in": "query",
        "required": false,
        "description": "Character you use to group keys.",
        "type": "string"
      },
      {
        "name": "encoding-type",
        "in": "query",
        "required": false,
        "description": "Requests Amazon S3 to encode the object keys in the response and specifies the encoding method to use. An object key may contain any Unicode character; however, XML 1.0 parser cannot parse some characters, such as characters with an ASCII value from 0 to 10. For characters that are not supported in XML 1.0, you can add this parameter to request that Amazon S3 encode the keys in the response.",
        "type": "string",
        "enum": [
          "url"
        ]
      },
      {
        "name": "key-marker",
        "in": "query",
        "required": false,
        "description": "Together with upload-id-marker, this parameter specifies the multipart upload after which listing should begin.",
        "type": "string"
      },
      {
        "name": "max-uploads",
        "in": "query",
        "required": false,
        "description": "Sets the maximum number of multipart uploads, from 1 to 1,000, to return in the response body. 1,000 is the maximum number of uploads that can be returned in a response.",
        "type": "integer"
      },
      {
        "name": "prefix",
        "in": "query",
        "required": false,
        "description": "Lists in-progress uploads only for those keys that begin with the specified prefix.",
        "type": "string"
      },
      {
        "name": "upload-id-marker",
        "in": "query",
        "required": false,
        "description": "Together with key-marker, specifies the multipart upload after which listing should begin. If key-marker is not specified, the upload-id-marker parameter is ignored.",
        "type": "string"
      },
      {
        "name": "MaxUploads",
        "type": "string",
        "in": "query",
        "description": "Pagination limit",
        "required": false
      },
      {
        "name": "KeyMarker",
        "type": "string",
        "in": "query",
        "description": "Pagination token",
        "required": false
      },
      {
        "name": "UploadIdMarker",
        "type": "string",
        "in": "query",
        "description": "Pagination token",
        "required": false
      },
      {
        "name": "uploads",
        "in": "query",
        "required": true,
        "type": "boolean",
        "allowEmptyValue": true,
        "enum": [
          true
        ]
      }
    ]
  }

requires max-uploads and MaxUploads, key-marker and KeyMarker, upload-id-marker and UploadIdMarker.
According to Amazon S3 API Reference you don't need both and you need them in PascalCase.

Incorrect usage of additional properties besides $ref for EC2 OpenAPI3 Swagger file

When I load up EC2 Swagger to the swagger editor, I see the following warnings:

According to the OpenAPI spec, any additional properties alongside $ref will be ignored: https://github.com/OAI/OpenAPI-Specification/blob/master/versions/3.0.3.md#referenceObject

This is causing issues in me trying to parse out the xml names of the parameters via an OpenAPI parser; because, as specified in the OpenAPI spec, the xml property beside $ref is ignored.

Wrong error response for HeadObject in s3

    head:
      operationId: HeadObject
      externalDocs:
        url: 'http://docs.amazonwebservices.com/AmazonS3/latest/API/RESTObjectHEAD.html'
      responses:
        '200':
          description: Success
          content:
            text/xml:
              schema:
                $ref: '#/components/schemas/HeadObjectOutput'
        '480':
          description: NoSuchKey
          content:
            text/xml:
              schema:
                $ref: '#/components/schemas/NoSuchKey'

NoSuchKey will be returned in 404 instead of 480, and maybe we don't need to include all error reponses here?

unexpected multi-type 'allOff' references in runtime.lex.v2 spec

the generated specification contains unexpected 'allOf' references: https://github.com/APIs-guru/openapi-directory/blob/main/APIs/amazonaws.com/runtime.lex.v2/2020-08-07/openapi.yaml

this brakes openAPi client generators: such as swagger-codegen maven plugin for java.

I'll suggest a PR later on this days

Unexpected "get" requests in generated openapi spec

The source spec for this doesn't have any mention of "GET" as far as I can tell, but the generated result has a "POST" and "GET" equivalent for every API call. I would expect just the "POST" version to show up because that's what's actually in the original definition.

It also causes some generation errors, which I think is because the generated code is trying to set query parameters from an object that it doesn't know how to turn into a string. For example:

error[E0599]: no method named `to_string` found for type `&models::tag::Tag` in the current scope

S3 API's error not handled correctly

    BucketAlreadyExists: {}
    BucketAlreadyOwnedByYou: {}

May be we need to fill the error type or just ignore them.

text/xml in iam spec instead of application/xml, which is what the OpenAPI 3.0 spec supports

The openapi spec only supports application/xml: https://github.com/OAI/OpenAPI-Specification/blob/master/versions/3.0.0.md (at least based on the fact that I can't find text/xml).

However, this spec uses text/xml: https://github.com/APIs-guru/openapi-directory/tree/master/APIs/amazonaws.com/iam/2010-05-08 I think these should be application/xml instead.

Incorrect variable type defined in the yaml file

Hi,

I'm an R package developer and find this project is very useful. Thanks for the hard works!

Recently I realize there is an incorrect variable type in the yaml file. The maxResults in ECS yaml is defined as a string, but its true type should be an integer as AWS documentation states. The AWS server would not accept the string type maxResults as the request parameter and will reject my REST request. That's how I find this error.

From its source file I did not find any incorrect content, so this might be due to some bugs in the converter and might affect the other variables as well. I can fix this in my package but I think it would be better to report this to you.

Best,
Jiefei

Converter missing response mappings

From @lihaoyi (li_haoyi on Twitter):

at least for the few AWS APIs I spot checked, like /#Action=DescribeInstances, the return structure is undefined (content: {}). Is this simply due to the API spec being incomplete, or am I missing something in how it is used?

Example is from the ec2 definition.

it seems your converter is missing the connection between DescribeInstances and DescribeInstancesResult, and also missing the locationName field in each of DescribeLocationResult's values that specifies what the XML key is going to be

Incorrect body for PutObject in Amazon S3

According to the PutObject operation documented in the AWS S3 Swagger doc here, the body takes the following format:

- name: body
          in: body
          required: true
          schema:
            type: object
            properties:
              Body:
                description: Object data.
                type: string
              x-amz-meta-:
                description: A map of metadata to store with the object in S3.
                type: object
                additionalProperties:
                  $ref: '#/definitions/MetadataValue'

According the the Amazon HTML REST API reference, the x-amz-meta- should be included in the request header. The Swagger doc states it is a body parameter. The Swagger doc is incorrect.

Duplicate Operation Paging Parameters (MaxResults and NextToken)

Some actions have duplicate parameters with different casing.
I think that they are referring to the same parameter.

Example: MaxResults and NextToken.

'/#Action=DescribeSpotFleetRequests':
    post:
      operationId: DescribeSpotFleetRequests
     ...
      parameters:
        - name: maxResults
          in: query
          required: false
          description: 'The maximum number of results to return in a single call.....value.'
          type: integer
        - name: nextToken
          in: query
          required: false
          description: The token for the next set of results.
          type: string
  ....
        - name: MaxResults
          type: string
          in: query
          description: Pagination limit
          required: false
        - name: NextToken
          type: string
          in: query
          description: Pagination token
          required: false

https://raw.githubusercontent.com/APIs-guru/openapi-directory/master/APIs/amazonaws.com/ec2/2016-11-15/swagger.yaml

Query parameters array "serialization" strategy

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

The "members" attribute in the AWS service definition is literally a list of "member" objects

In the AWS service definition you're using as a source for this, there's a "members" field:

"ListUsersResponse": {
  "type": "structure",
  "required": [
    "Users"
  ],
  "members": {
    "Users": {
      "shape": "userListType",
      "documentation": "<p>A list of users.</p>"
    },
    ...
}

You reasonably assumed that "members" is a structural thing to describe what members a "ListUsersResponse" has, and have changed it to "properties" in your generated OpenAPI spec:

ListUsersResponse:
   type: object
   required:
     - Users
   properties:
     Users:
       $ref: '#/components/schemas/userListType'
       description: A list of users.
     ...

However, when hitting the API directly using https://github.com/okigan/awscurl and https://github.com/sverch/aws-signature-proxy, the response actually has "member" sub-objects in it:

$ https_proxy=localhost:8080 curl "https://iam.amazonaws.com/?Action=ListUsers&Version=2010-05-08"
<ListUsersResponse xmlns="https://iam.amazonaws.com/doc/2010-05-08/">
  <ListUsersResult>
    <IsTruncated>false</IsTruncated>
    <Users>
      <member>
        ...
        <UserName>shaun.verch</UserName>
        <Arn>arn:aws:iam::ID:user/shaun.verch</Arn>
        ...
      </member>
    </Users>
  </ListUsersResult>
...
</ListUsersResponse>

When I hit an endpoint that returns multiple results (ListRoles), it actually returns multiple "member" objects rather than multiple "Roles".

Body in PutObject, UploadPart API's type should by string instead of object

May be we should convert following pattern:

schema:
  type: object
  properties:
    Body:
      description: Object data.
      type: string

schema:
  type: string
  format: binary

PutObject 's body should be content of this object in sequence of octets

Add tests using moto and pyopenapi

The AWS v4 signing process makes it difficult to test that these specs actually work against the real AWS API, but moto has an option to disable authentication, and has a "standalone server" mode where it looks like the AWS API (which is why it's the basis of localstack).

I think it would be possible to get some local tests running (and even some CI) by using this, perhaps using something like pyopenapi.

The "operationId" field shouldn't have spaces

While the spec doesn't specifically say that spaces aren't allowed, it did say this:

operationId	string	Unique string used to identify the operation. The id MUST be unique among all operations described in the API. The operationId value is case-sensitive. Tools and libraries MAY use the operationId to uniquely identify an operation, therefore, it is RECOMMENDED to follow common programming naming conventions.

I ran into a generator that followed that convention, and ended up with some broken code. I think since the spec recommends that operationId follows common programming naming conventions, it should be fixed here rather than in the generator.

Exception definitions not included

There appear to be missing definitions for exceptions. For example InvalidArn is one of the exceptions in the states SDK API but the definition is missing in the generated schema

  schemas:
    ...
    InvalidArn: {}

From what I can see, this info is simply absent in the library being used as the source for these outputs.

It is however present in the v3.x package aws-sdk-js-v3, but I can see this library is targetting the v2.x package aws-sdk-js/.

For context, I was hoping to develop an approach to ingest boto3 Python client responses off the back of this work, but since the errors are not available any data model I can produce would be incomplete.

I guess the question I have in this issue is whether there are plans to move on to target the v3.x package?

Missing "https" protocol in "schemes"?

All the generated swagger specs have "schemes": ["http"] only. It should be probably https or both?

Swagger validation errors: additional properties - shape, documentation

I get schema validation errors when trying to run the current version of this tool. Steps to reproduce are:

git clone <aws2openapi url>
git clone <openapi-directory url>
git clone <aws-sdk-js url>
cd aws2openapi
npm install
. processYaml.sh

Example error output from processing just one API:

node aws2openapi.js ../aws-sdk-js/apis/cloudformation-2010-05-15.normal.json ../openapi-directory/APIs/amazonaws.com -y
/home/mark/oss/aws-sdk-js/apis/cloudformation-2010-05-15.normal.json
  Has paginators
  Has examples version 1.0
  Has waiters version 2
{"serviceName":"cloudformation","versions":[],"preferred":"2010-05-15"}
/home/mark/oss/aws-sdk-js/apis/cloudformation-2010-05-15.normal.json
Failed validation (simple): /home/mark/oss/aws-sdk-js/apis/cloudformation-2010-05-15.normal.json
[ { field: 'data.definitions',
    message: 'referenced schema does not match' } ]
/home/mark/oss/aws-sdk-js/apis/cloudformation-2010-05-15.normal.json
{
  "details": [
    {
      "code": "ANY_OF_MISSING",
      "params": [],
      "message": "Data does not match any schemas from 'anyOf'",
      "path": [
        "definitions",
        "TransformsList",
        "items"
      ],
      "schemaId": "http://swagger.io/v2/schema.json#",
      "inner": [
        {
          "code": "OBJECT_ADDITIONAL_PROPERTIES",
          "params": [
            [
              "shape"
            ]
          ],
          "message": "Additional properties not allowed: shape",
          "path": [
            "definitions",
            "TransformsList",
            "items"
          ],
          "description": "A deterministic version of a JSON Schema object."
        },
        {
          "code": "INVALID_TYPE",
          "params": [
            "array",
            "object"
          ],
          "message": "Expected type array but found type object",
          "path": [
            "definitions",
            "TransformsList",
            "items"
          ]
        }
      ]
    }
  ],
  "name": "SyntaxError",
  "message": "Swagger schema validation failed. 
  Data does not match any schemas from 'anyOf' at #/definitions/TransformsList/items
    Additional properties not allowed: shape at #/definitions/TransformsList/items
    Expected type array but found type object at #/definitions/TransformsList/items
 
JSON_OBJECT_VALIDATION_FAILED",
  "stack": "SyntaxError: Swagger schema validation failed. 
  Data does not match any schemas from 'anyOf' at #/definitions/TransformsList/items
    Additional properties not allowed: shape at #/definitions/TransformsList/items
    Expected type array but found type object at #/definitions/TransformsList/items
 
JSON_OBJECT_VALIDATION_FAILED
    at validateSchema (/home/mark/oss/aws2openapi/node_modules/swagger-parser/lib/validators/schema.js:27:15)
    at /home/mark/oss/aws2openapi/node_modules/swagger-parser/lib/index.js:152:9
    at process._tickCallback (internal/process/next_tick.js:68:7)
    at Function.Module.runMain (internal/modules/cjs/loader.js:745:11)
    at startup (internal/bootstrap/node.js:279:19)
    at bootstrapNodeJSCore (internal/bootstrap/node.js:752:3)

z-schema validation error: JSON_OBJECT_VALIDATION_FAILED
    at ZSchema.getLastError (/home/mark/oss/aws2openapi/node_modules/z-schema/src/ZSchema.js:260:13)
    at validateSchema (/home/mark/oss/aws2openapi/node_modules/swagger-parser/lib/validators/schema.js:25:23)
    at /home/mark/oss/aws2openapi/node_modules/swagger-parser/lib/index.js:152:9
    at process._tickCallback (internal/process/next_tick.js:68:7)
    at Function.Module.runMain (internal/modules/cjs/loader.js:745:11)
    at startup (internal/bootstrap/node.js:279:19)
    at bootstrapNodeJSCore (internal/bootstrap/node.js:752:3)"
}

The generated yaml files are different than those currently in the openapi-directory repo. Here's an example of the diff:

+++ b/APIs/amazonaws.com/cloudformation/2010-05-15/swagger.yaml
@@ -1617,11 +1617,11 @@ definitions:
       - StackName
     properties:
       StackName:
-        $ref: '#/definitions/StackName'
-        description: The name or the unique stack ID that is associated with the stack.
+        shape: StackName
+        documentation: <p>The name or the unique stack ID that is associated with the stack.</p>
       ClientRequestToken:

Notice that "shape" should have transformed into a "$ref" and "documentation" into "description", but that did not happen.

Non-Routable Swagger

Hello,

It appears that the Swagger/OpenAPI definitions you generate for the AWS APIs are "client side only". We have a need for a "server side" version. The difference can be seen in APIs like ACM where the Swagger is using the root (/) path with a number of hashes (/#DescribeCertificate) to differentiate the supplied JSON request body. Well, this hash-based path isn't "routable" in terms of a server as clients are really going to supply the hash, this is more a mechanism for you to overload the definition of the root path. Can you think of a way to make these Swagger files support both a client with the proper body but also the routable server? I realize that the Swagger specification does a real poor job of defining what the paths should be but to me, hashes are sort of abusing it.

Thanks.

The info.contact.x-twitter field causes openapi-generator to fail

I'm trying to use the aws specs generated by this project in https://github.com/OpenAPITools/openapi-generator/, but I hit this error:

Exception in thread "main" org.openapitools.codegen.SpecValidationException: There were issues with the specification. The option can be disabled via validateSpec (Maven/Gradle) or --skip-validate-spec (CLI).
 | Error count: 1, Warning count: 165
Errors: 
	-attribute info.contact.x-twitter is unexpected
Warnings: 
	-attribute info.contact.x-twitter is unexpected

	at org.openapitools.codegen.config.CodegenConfigurator.toContext(CodegenConfigurator.java:424)
	at org.openapitools.codegen.config.CodegenConfigurator.toClientOptInput(CodegenConfigurator.java:453)
	at org.openapitools.codegen.cmd.Generate.run(Generate.java:407)
	at org.openapitools.codegen.OpenAPIGenerator.main(OpenAPIGenerator.java:60)

Here's the script I'm using to run the generator:

#!/bin/bash

# http://redsymbol.net/articles/unofficial-bash-strict-mode/
set -euo pipefail

NUM_ARGS_REQUIRED=1
if [ $# -ne "${NUM_ARGS_REQUIRED}" ]; then
    cat <<EOF
Usage: $0 <openapi-directory>

    Try to generate IAM from openapi directory.

EOF
    exit 1
fi

run () {
    echo "+" "$@" 1>&2
    "$@"
}

OPENAPI_DIRECTORY=$1

pushd "${OPENAPI_DIRECTORY}/APIs/amazonaws.com/iam/2010-05-08"
docker run --rm -v "${PWD}:/local/out/rust/" openapitools/openapi-generator-cli generate \
    -i /local/out/rust/swagger.yaml \
    -g rust \
    -o /local/out/rust/generated \
    --additional-properties packageName=aws_iam_client --library=reqwest
popd

Test

This is for a test of the GraphQL API

Bad regex for Lambda S3Bucket Definition

Here's the regex

That regex is matched by foo(?<!.) but not foo. I think the second half of the regex, $\?<!\.$, is meant to be a lookahead or something...

Openapi for endpoints that have pagination end up with duplicate parameters

Here is a link to the openapi.json for Amazon Connect Service https://api.apis.guru/v2/specs/amazonaws.com/connect/2017-08-08/openapi.json

In the above file #/paths/~1contact-flows-summary~1{InstanceId}/get/parameters is

        "parameters": [
          {
            "description": "The identifier of the Amazon Connect instance.",
            "in": "path",
            "name": "InstanceId",
            "required": true,
            "schema": {
              "maxLength": 100,
              "minLength": 1,
              "type": "string"
            }
          },
          {
            "description": "The type of contact flow.",
            "in": "query",
            "name": "contactFlowTypes",
            "required": false,
            "schema": {
              "items": {
                "$ref": "#/components/schemas/ContactFlowType"
              },
              "maxItems": 10,
              "type": "array"
            }
          },
          {
            "description": "The token for the next set of results. Use the value returned in the previous response in the next request to retrieve the next set of results.",
            "in": "query",
            "name": "nextToken",
            "required": false,
            "schema": {
              "type": "string"
            }
          },
          {
            "description": "The maximum number of results to return per page.",
            "in": "query",
            "name": "maxResults",
            "required": false,
            "schema": {
              "maximum": 1000,
              "minimum": 1,
              "type": "integer"
            }
          },
          {
            "description": "Pagination limit",
            "in": "query",
            "name": "MaxResults",
            "required": false,
            "schema": {
              "type": "string"
            }
          },
          {
            "description": "Pagination token",
            "in": "query",
            "name": "NextToken",
            "required": false,
            "schema": {
              "type": "string"
            }
          }
        ],

Note there is nextToken and NextToken, and maxResults and MaxResults. However, there are only four parameters in the API reference https://docs.aws.amazon.com/connect/latest/APIReference/API_ListContactFlows.html

I believe the problem stems from the existence of pagination functions in the SDK, e.g. aws-sdk-js-v3//clients/client-connect/pagination/ListContactFlowsPaginator.ts which are unioned with the clients e.g. aws-sdk-js-v3//clients/client-connect/commands/ListContactFlowsCommand.ts, resulting in the duplicate parameters. There are 186 directories named pagination within the entire corpus of the aws-sdk so this is potentially a massive issue.

Support signatureVersion: bearer

For this and other issues, we may be able to learn things from fromsmithy

Support AWS per-region hosts

The current code always outputs <endpointprefix>.amazonaws.com as the host for every spec. That is often (but not always) one correct host, but there's typically many other valid hosts, usually one for each AWS region.

This results in specs that a) don't represent all valid hosts, and b) sometimes don't represent any valid hosts, e.g. the SQS spec uses sqs.amazonaws.com, which doesn't even have a DNS record. SQS requests should instead be sent to sqs.<region-name>.amazonaws.com e.g. sqs.us-east-1.amazonaws.com (see https://docs.aws.amazon.com/general/latest/gr/rande.html#sqs_region).

Imo, it would be better if the specs included the valid host URLs. Fortunately the logic to work out all the valid hosts isn't too bad, the rules are documented at https://github.com/aws/aws-sdk-js/blob/master/lib/region_config_data.json, with associated logic at https://github.com/aws/aws-sdk-js/blob/master/lib/region_config.js.

The hard part is how to output this. I'm happy to put together a PR for this, but OpenAPI v2 only allows a single host, so this isn't representable. I can see a couple of sensible options:

Convert to OpenAPI v3 first, then use OpenAPI v3's templated servers field
Add a custom field emulating this temporarily for v2, e.g. x-v3-servers, which exactly matches the format for v3, so tools that are aware of it can use it whilst others use the existing host field. Swagger2openapi can then just rename it when converting to v3.

I've got some time to put together a PR for this, but not really to convert all this logic to v3 beforehand. Any chance you do? Otherwise, what do you think we should do?

403 Forbidden errors when using swagger client

I'm trying to use npm module swagger-client along with the AWS swagger specs generated by aws2openapi and am running into some trouble.

More specifically, I'm using the cloudformation swagger spec from here:
https://github.com/APIs-guru/openapi-directory/raw/master/APIs/amazonaws.com/cloudformation/2010-05-15/swagger.yaml

And performing the following:

Load cloudformation swagger spec from file
Call swagger-client resolve with the spec to resolve $refs
Call swagger-client buildRequest with the resolved spec, operationId, and parameters, including Action and Version.
Remove the #Action portion of the URL returned from buildRequest
Use aws4 to sign the request and generate the correct region-specific URL
Use node-fetch with the signed request against the actual AWS API endpoint generated by aws4

In response, I get a 403 Forbidden error with the following info:

<AccessDeniedException>
  <Message>Unable to determine service/operation name to be authorized</Message>
</AccessDeniedException>

I believe the problem is that the generated swagger spec is incorrect in specifying that Version and Action should be in the HTTP headers. And therefore, the request that buildRequest creates has the Version and Action parameters in the HTTP header. However, the AWS docs only describe putting these parameters in the query parameter portion of the URL. And looking at the requests that the official AWS Javascript SDK generate, those also put Version and Action in query parameters.

Have you tested generating requests that require the Action parameter using v4 authentication? If so, would you point me to those tests so I can see if there's something I might be doing wrong?

I have found that by changing the swagger spec for cloudformation to have Version and Action be in query instead of in header, that I can get successful responses from AWS. I'll submit a pull request for a change to aws2openapi that seems to work well for me.

*There is a small caveat to getting successful requests: the URL generated by swagger-client has to be edited to remove the hash portion that's in the swagger path entry. I think open issue #2 essentially covers this problem and I don't really have any good ideas for a better solution other than to just edit the URL.

AWS Lambda Blob format incorrect

The Blob definition is defined here. A Blob is used in a few locations, one of which is in a Code object here. According to the AWS API Reference doc, this should be encoded as "Base64-encoded binary data object." Swagger has support for Base64 encoded content by using the format: byte property. The Blob format property is currently set to password. I believe it should be set to byte.

Duplicate entries in Servers Object

Link to full JSON: https://api.apis.guru/v2/specs/amazonaws.com/backup/2018-11-15/openapi.json

servers list has duplicated entries.

"servers": [
    {
      "url": "http://backup.{region}.amazonaws.com",
      "variables": {
        "region": {
          "description": "The AWS region",
          "enum": [
            "us-east-1",
            "us-east-2",
            "us-west-1",
            "us-west-2",
            "us-gov-west-1",
            "us-gov-east-1",
            "ca-central-1",
            "eu-north-1",
            "eu-west-1",
            "eu-west-2",
            "eu-west-3",
            "eu-central-1",
            "eu-south-1",
            "af-south-1",
            "ap-northeast-1",
            "ap-northeast-2",
            "ap-northeast-3",
            "ap-southeast-1",
            "ap-southeast-2",
            "ap-east-1",
            "ap-south-1",
            "sa-east-1",
            "me-south-1"
          ],
          "default": "us-east-1"
        }
      },
      "description": "The AWS Backup multi-region endpoint"
    },
    {
      "url": "https://backup.{region}.amazonaws.com",
      "variables": {
        "region": {
          "description": "The AWS region",
          "enum": [
            "us-east-1",
            "us-east-2",
            "us-west-1",
            "us-west-2",
            "us-gov-west-1",
            "us-gov-east-1",
            "ca-central-1",
            "eu-north-1",
            "eu-west-1",
            "eu-west-2",
            "eu-west-3",
            "eu-central-1",
            "eu-south-1",
            "af-south-1",
            "ap-northeast-1",
            "ap-northeast-2",
            "ap-northeast-3",
            "ap-southeast-1",
            "ap-southeast-2",
            "ap-east-1",
            "ap-south-1",
            "sa-east-1",
            "me-south-1"
          ],
          "default": "us-east-1"
        }
      },
      "description": "The AWS Backup multi-region endpoint"
    },
    {
      "url": "http://backup.{region}.amazonaws.com.cn",
      "variables": {
        "region": {
          "description": "The AWS region",
          "enum": [
            "cn-north-1",
            "cn-northwest-1"
          ],
          "default": "cn-north-1"
        }
      },
      "description": "The AWS Backup endpoint for China (Beijing) and China (Ningxia)"
    },
    {
      "url": "https://backup.{region}.amazonaws.com.cn",
      "variables": {
        "region": {
          "description": "The AWS region",
          "enum": [
            "cn-north-1",
            "cn-northwest-1"
          ],
          "default": "cn-north-1"
        }
      },
      "description": "The AWS Backup endpoint for China (Beijing) and China (Ningxia)"
    }
  ]

x-amz-meta- is wrong for AWS S3 PutObject API

I believe x-amz-meta- should be in header instead of requestBody in AWS S3 PutObject API:

      requestBody:
        required: true
        content:
          text/xml:
            schema:
              type: object
              properties:
                Body:
                  description: Object data.
                  type: string
                x-amz-meta-:
                  description: A map of metadata to store with the object in S3.
                  type: object
                  additionalProperties:
                    $ref: '#/components/schemas/MetadataValue'

ref: https://docs.aws.amazon.com/AmazonS3/latest/API/API_PutObject.html#API_PutObject_RequestSyntax