-
-
Notifications
You must be signed in to change notification settings - Fork 762
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Feature/multiple yaml same base path #1598
Feature/multiple yaml same base path #1598
Conversation
699d860
to
25172a9
Compare
Pull Request Test Coverage Report for Build 3144853041
💛 - Coveralls |
Thanks @leonardofesta!
I don't really like this behavior as it is not the behavior I would expect. I think ideally we would:
I think this behavior is generated by the combined behavior of Flask Blueprints and how apis are registered in our RoutingMiddleware (see #1489 for background): connexion/connexion/middleware/routing.py Lines 94 to 114 in 181c61b
I don't immediately see a way to get the desired behavior without big changes in how routing works. |
Updated my comment above after having a second look. |
Yes, it doesn't seem straightforward. As far as I understood for each add_api() we create a blueprint and a starlette router. Also from the starlette router, in their documentation on routing they specify they use a policy of priority on routes, in case of conflicts first win. The second issue where you get 405 for same path and different method, I think is caused also from starlette implementation for this piece of code here They have this concept of partial match. When the path is registered but the method is not present, it causes an exception and returns 405 meethod not allowed. |
Closing in favor of #1736. I cherry-picked your commits there. |
Fixes #1542 .
Changes proposed in this pull request:
It is possible to pass a name parameter to the connexion.app_api(..) method
the name parameter will be assigned to the Flask blueprint
in case you don't pass the name, it will rely on previous/default behaviour (base path as name in Flask case)
Having multiple specification in the same path, opens to new conflicting case.
In case the same endpoint is defined from 2 specs, the first one added and covering the case will be accepted, the second one ignored.
A more niche case, in case you define 2 operation on the same path but different method, the second one won't work, even if they are complementary.
Eg:
spec1 get foo/
spec2 post foo/
if you call post foo/ --> response will be 405, method not allowed (it ignores 2nd definition of the same path)
I think these cases can be fine as long they are documented (let me know where do you think I should amend the documentation).
Let me know if you want more unit tests
Ps: sorry for the mess on the other pr, somehow a work account. ended up as commentor