I'm deploying a python flask application to AWS Lambda, served through AWS API Gateway using Serverless Framework.
Everything works great, except the swagger ui when served on AWS.
Currently, my application (dev version) is deployed to some address:
Swagger ui is indeed accessible at:
The problem is, it tries to load the openapi.json file from the root path:
instead of the relative path:
If I change the "explore" URL to "/dev/openapi.json" manually at the top of the page, the UI loads, but then again, "trying out" endpoints through the UI calls endpoints at the root instead of the relative path:
If I set the base path to /dev in the specification using the servers setting, the ui is no longer accessible at /dev/ui. It's then served at /dev/dev/ui.
Then again, I need to change the "explore" url to /dev/dev/openapi.json and all calls are sent to /dev/endpoint instead of /dev/dev/endpoint.
Am I missing something? Or does swagger ui doesn't support this use case?
The only solution I can think of is deploying the api to different API Gateways, so that the basepath will always be:
How do you deploy Swagger UI to AWS?
Based on the way you describe the issue, it seems the problem is potentially with the definition itself as well. Can you share what your 'servers' definition looks like?
Thanks for your reply.
It's a flask app, using swagger with the help of connexion and deployed to AWS using Serverless Framework.
By default I have no "servers" definition as the default ('/') works just fine when developing and when loading on aws (the ui loads but without the openapi.json as I described before).
When I talked about setting '/dev' as the base path I set it like this:
description: Development server (uses dev data)
Thanks for the additional details.
I imagine you're including Swagger UI as a connexion module, and not deploying it on your own. Based on what you're describing, it seems like an issue with the connexion configuration rather than with Swagger UI.
Swagger UI has no impact on where it is served from. The URL it loads depends on the 'url' parameter in its configuration, so if it doesn't load the file properly, it means the URL being fed to it is wrong.
The try it out functionality depends on the API definition itself, as you already figured out. The catch is that if a relative URL is being used in the 'servers', then it will be relative to the location of the 'openapi.yaml' file.
As a first step of solving this, try fixing the configuration in connexion so that it loads the right URL from start. Unfortunately, connexion is not one of our projects, and I don't know well it enough to guide you towards how to do that.
Thanks a lot for the help, will try it.
If anyone else is interested, I think the relevant connexion issue on github is this.