I was writing the documentation on exception handling, and I noticed
that it was very hard to explain our current behavior.
Error handlers can be registered either on the internal Flask app (not
the Starlette one) or on the Connexion app, which leads to some
undefined (actually just really hard to explain) behavior. Eg.
- Registering error handlers on a status code would capture
`starlette.HTTPException` errors on the Connexion app, and
`werkzeug.HTTPException` errors on the Flask App, which means that
registering an error handler on a status code doesn't catch all the
errors with that status code.
- Flask does some default error handling which leads to some exceptions
never reaching the error handlers registered on the Connexion app.
So I made the following changes:
- Replaced the default error handlers we registered on the Flask app
with a default handler on the `ExceptionMiddleware` that takes into
account other handlers registered on status codes.
- Configured Flask to propagate exceptions instead of catching them.
- Abstracted away the Starlette `Request` and `Response` types, so users
can and must now use `ConnexionRequest`
and `ConnexionResponse` types in error handlers.
- Renamed the `ASGIRequest` class to `ConnexionRequest` since it is the
only Request class part of the high level
Connexion interface.
We could also rename `ConnexionRequest` and `ConnexionResponse` to just
`Request` and `Response`. Wdyt?
* Add a relative resolver
* Fix super() usage
* Apply suggestions from code review
* Allow root_path to be a Python module
* Expand documentation for RelativeResolver
* Add tests for relative resolver
Fixes#206 - Handle nested paths in swagger definitions.
- Allow nested paths to be handled in `get` and `search` handlers
An explicit decision has been made to resolve paths (with a prefix like `my.api`) like:
- `/hello/{hello_id}/world` --> `my.api.hello.world:search(hello_id)`
- `/hello/world/{world_id}` --> `my.api.hello.world:get(world_id)`
* Added MethodViewResolver
By subclassing RestyResolver and modifying its `resolve_function_from_operation_id` method, it is now possible to use automatic routing functionality with Flask's MethodView together with MethodViewResolver.
* Add MethodView example
* Add tests for methodview
* add documentation on how to use MethodViewResolver
removed test_decorators and test_parameter (this test is useless now);
removed the request/response containers and add new request response classes;
created a abstract api class and a api flask class;
derived classes will implements the get_response/get_request methods that will convert framework req/resp types to connexion req/resp types;
moved the jsonifier from produces to flask api;
created a abstract app class and a app flask class;
changed all validators to use the ConnexionRequest instead flask request;
changed the problem function to generate a ConnexionRequest;
created a new user variables container called context (this is a property of ConnexionRequest). this will be passed as kwargs to all operations functions;
this context is used on authentication;
fixed all tests to new API;
some changes that I did may not be documented in this commit.
Without sanitization e.g. OData query parameters, such as $skip, $top,
$filter cannot be passed to the controller (except by use of **kwargs).
Fixes: zalando/connexion#334
