Unable to correctly import an OpenAPI 3.0 to API Gateway v2

0

Trying to import an OpenAPI 3.0 definition generated by FastAPI. The API only gets imported partially, and these warnings are listed in the response:

"Warnings": [
    "Parse issue: attribute components.schemas.Place.items is not of type `object`",
    "Parse issue: attribute components.schemas.Place.items is missing",
    "Unable to put method 'PUT' on resource at path '/place/': Part of the given route key path is empty Ignoring.",
    "Unable to put method 'GET' on resource at path '/schedule/': Part of the given route key path is empty Ignoring.",
    "Unable to put method 'PUT' on resource at path '/schedule/': Part of the given route key path is empty Ignoring.",
    "Unable to put method 'POST' on resource at path '/schedule/': Part of the given route key path is empty Ignoring.",
    "Unable to put method 'POST' on resource at path '/booking/': Part of the given route key path is empty Ignoring."
]

The process is importing only 1 method per route. As a workaround I can use the old REST API, but if anyone has any idea on how to fix this for the HTTP that would be helpful. Thanks!

scezar
asked 2 years ago1990 views
1 Answer
1

Please check if any of the limitations mentioned in this document https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-known-issues.html under the section "API Gateway supports most of the OpenAPI 2.0 specification and the OpenAPI 3.0 specification, with the following exceptions:" apply to you.

Is your imported API working correctly when using REST API as opposed to HTTP API. In that case, using REST API is probably a better option for you. You can use this document https://docs.aws.amazon.com/apigateway/latest/developerguide/http-api-vs-rest.html to see the differences between the two and make an informed decision.

profile pictureAWS
EXPERT
answered 2 years ago
  • Those limitations don't seem to apply. Also that document only talks about REST and WebSocket APIs, and REST works fine so I'll probably use that for now. But the HTTP API seems to be more fit for my application.

  • Yes if REST is working for you, please go ahead with REST. Functionally there is very little that can be done with HTTP that cannot be done with REST. But interested to know why you think HTTP API is a better fit for your application.

You are not logged in. Log in to post an answer.

A good answer clearly answers the question and provides constructive feedback and encourages professional growth in the question asker.

Guidelines for Answering Questions