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
Add note about Body parameters #900
Conversation
Add a link to section containing the documentation for Body parameters, emphasizing that using Pydantic models is not mandatory.
Codecov Report
@@ Coverage Diff @@
## master #900 +/- ##
=====================================
Coverage 100% 100%
=====================================
Files 293 293
Lines 7692 7701 +9
=====================================
+ Hits 7692 7701 +9
Continue to review full report at Codecov.
|
Thanks for your contribution! 🎉 🍰 |
I tripped on this as well. And I really think it would be awesome to have FastAPI work with properly annotated but otherwise "unmodified" python functions and this "Body(...)" departs from that and is quite ugly I would say. May I suggest we change the @app.post to: - Suggestion 1: add a "param-lookup" argument to the post decorator so that we could specify the order in which FastAPI will look for 'non-path' and non BaseModel descendants parameters. It could be "query, body", "body, query", "query" or "body". Current default is "query", but should be changed to "query, body". - Suggestion 2: add a "fallback-to-body" argument to the decorator, so if a parameter is missing after looking for them in the query string, FastAPI would then check the request body for them. If any of these suggestions sound ok, I could try developing it and submitting a pull request. Just let me know if it would be welcomed. |
The "Body(...)" workaround also has the limitation described here: #1011 |
I think it's quite consistent to have In any case, since the implicit behavior can become quite confusing with lots of parameters (default to query, pydantic models as body, params in the route as path, etc.), I think it's best to always be explicit and wrap your parameters in But I'm concerned by the issue your references, as I thought using |
While pydantic and FastAPI will understand the parameter as being mandatory, linters and cpython will see it as optional and it is an error in python to have optional parameters preceeding non-optional parameters so it may force one to reorder parameters around. Also, I really do not understand why it would be a bad idea to fallback to checking for parameters in the body, even if you choose to limit this behavior to post method and when the body content type is form or json. May I suggest two more alternatives? Suggestion 3: Have the decorator accept kwargs like this: @app.post('/', a = Body(...), b = Path(...), c = Query(...)) Suggestion 4: create type alias to indicate where the parameters will be found somewhere on FastAPI codebase:TPath = typing.Union @app.post('/') |
Add a link to section containing the documentation for Body parameters, emphasizing that using Pydantic models is not mandatory.
It's a follow-up for issue #895. Me and another colleague had the same trouble, thinking that Pydantic models were mandatory to accept params in the request body.
Waiting for your feedback of course as I wrote this note quickly, just to initiate the PR.