Replies: 10 comments 1 reply
-
I may be wrong, but I'm not aware of a redirect from /docs to /openapi.json, there is effectively /docs doing a xhr to get it but no redirect. |
Beta Was this translation helpful? Give feedback.
-
@euri10 When I check the network tab in chrome developper tools, I see a GET request to url/api/v1/openapi.json after I attempted a GET request to /docs My issue isn't the route really, it's the IP that it's trying to hit. The order of request goes:
The |
Beta Was this translation helpful? Give feedback.
-
Yes, I would suggest a better way (depends on point of view). I would use Traefik, integrated into Docker (and Docker Compose). And then set the rules of which service should take which path in labels in each service, instead of a lot of configurations that have to be updated and kept in sync in a separated Nginx service. That's all already done and preconfigured for you to use, you can try one of the project generators. It takes 2 minutes to generate a directory with everything set up, and all integrated with Docker Compose: https://fastapi.tiangolo.com/project-generation/ |
Beta Was this translation helpful? Give feedback.
-
I strongly support the recommendation to use Traefik - makes reverse proxying to docker services really, really easy and configurable. Also handles rate-limiting, round-robin/etc routing, route-level middleware, path conversions, ... |
Beta Was this translation helpful? Give feedback.
-
I'll assume you were able to solve your problem and I'll close this issue, but feel free to add more comments or create new issues. |
Beta Was this translation helpful? Give feedback.
-
hi @pgarneau . i have the same issue with openapi not working with nginx url re-write. can you share the code snippet as to how you solved the issue. |
Beta Was this translation helpful? Give feedback.
-
Hi @pgarneau , I'm facing same issue. could you please share the code snippet of workaround you implemented? |
Beta Was this translation helpful? Give feedback.
-
Quickfix: Add a new location that informs clients that the spec has moved permanently to where the API actually lives.
Logic: Adding a location for that route specifically can patch this. You will get problems if you have multiple versions of an API or multiple independent APIs on the same server (all will request the same |
Beta Was this translation helpful? Give feedback.
-
https://fastapi.tiangolo.com/advanced/extending-openapi/#the-normal-process
Basically you can change where the openapi.json is by overriding the openapi_url parameter as detailed in the help docs (link above). You can also override the /docs or /redocs endpoints with whatever you want (I did that using Nils de Bruins blog post instructions to restrict access to anyone not logged in using cookie-based tokens for the API docs). |
Beta Was this translation helpful? Give feedback.
-
@wshayes Yes, exactly. You will need some additional plumbing though to make it play nice with Nginx. Consider main.pyfrom fastapi import FastAPI
import uvicorn
from fastapi.openapi.utils import get_openapi
app = FastAPI(
openapi_url="/v1/docs"
)
@app.get("/")
async def root():
return {"message": "Hello World"}
if __name__ == "__main__":
uvicorn.run(app, host="0.0.0.0", port=8000) and server.conf
as well as the following way to bring it together docker-compose.yml
Now the spec lives at
The more interesting question is how to solve the problem for multiple APIs (as posed by the OP). The cleanest way I can think of is adding (warning: untested)
or a single location block for every API as suggested above. This way, the api doesn't need to know where it actually ends up living on the server (which may be different for dev, stage, production). It is not ideal, because the API still has to know about it's version, and (more importantly) adding a new API means changing |
Beta Was this translation helpful? Give feedback.
-
Hello there!
I am running an nginx reverse proxy with multiple fastapi microservices with the use of docker-compose. I am trying to give access to each microservice's documentation by configuring a proxy_pass from route /docs/serviceName to the microservice's doc. For example, here's the nginx config:
This proxy_pass works just fine, but my browser then tries to access
http://localhost:8000/api/v1/openapi.json
instead ofhttp://localhost:8001/api/v1/openapi.json
where theconfiguration-service
is located.A workaround that I found was to proxy_pass the
/api/v1/openapi.json
route to myconfiguration-service
and it works, but once I start adding more services to my docker-compose, I will have to define a uniqueopenapi_prefix
for each and have 2 proxy_pass configurations in my nginx container for each.Is there any other option?
Thank you!
Beta Was this translation helpful? Give feedback.
All reactions