Fastapi: [FEATURE] Support body in GET and other methods with undefined behavior

Created on 17 Nov 2019  Â·  15Comments  Â·  Source: tiangolo/fastapi

Describe the bug
In new version of rest api specification get methods can have body but fastapi not add it to swagger spec.

To Reproduce
Steps to reproduce the behavior:
Create get method with some body parameters.

Expected behavior
Body parameters present in the specification.

Environment:

  • OS: Windows
  • FastAPI Version: 0.42.0
  • Python version, get it with: 3.8
answered confirmed enhancement

Most helpful comment

working on this.

All 15 comments

Same for me -> No request body appears in swagger doc for get method (using pydantic for input arguments).
Environment:

➜  shell git:(feature/refacto_shell) ✗ uname -a
Linux DESKTOP-AAJBFKM 4.4.0-18362-Microsoft #476-Microsoft Fri Nov 01 16:53:00 PST 2019 x86_64 GNU/Linux
➜  shell git:(feature/refacto_shell) ✗ python --version
Python 3.7.2
➜  shell git:(feature/refacto_shell) ✗ pipdeptree -p fastapi
fastapi==0.42.0
  - pydantic [required: >=0.32.2,<=0.32.2, installed: 0.32.2]
  - starlette [required: >=0.12.9,<=0.12.9, installed: 0.12.9]

Route/entities definition:
image

image

Swagger webserver => can't see request body for this route (ExtractedSkillsFormationRequest):
image

No sign of ExtractedSkillsFormationRequest in generated openapi schema (from http://127.0.0.1:8001/openapi.json):
image

Hope this informations can help ...

After some investigations, i found some clues ;-):
https://github.com/tiangolo/fastapi/blob/master/fastapi/openapi/utils.py#L175:
image

https://github.com/tiangolo/fastapi/blob/master/fastapi/openapi/constants.py:
image

GET is not present in METHODS_WITH_BODY.

If we fix this, for example by adding GET or change a bit the condition to known if we need request_body like this:
image
we can get (back) request body in SwaggerUI:
image
(with a correct curl command)
with a better openapi schema:
image

But we can't use Execute button to launch a request:
image

That's seems a known bug:

... but it beyond my competence/knownledge :'(

I also searched a bit on this topic. The HTTP spec suggests not having a request body in the GET method.
The only meaning of having body is that you want request body contains the very long query params. But think again, how do you make a simple request from a browser (which is basically GET) with such request body? Now perhaps you think you can write to support both scenarios. Then, the swagger is now also doubled with the query params model.

In short, It's not a good practice to have request body in GET method. I'm against marking this as a [BUG].
Even we support request body in FastAPI context, there is a lot of clients will not work properly.

We have the proxy to elastic search and it has get endpoint. How do we support a body description for these methods without change request on post? Support body in get is very necessary.

@heckad if you read the doc in the given url, they said POST is supported. So if you are proxy-ing the GET request, within FastAPI you can turn the request into a POST request to ElasticSearch.

But we don’t want to cost only to support the old version of RFC.

Update The RFC2616 referenced as "HTTP/1.1 spec" is now obsolete. In 2014 it was replaced by RFCs 
7230-7237. Quote "the message-body SHOULD be ignored when handling the request" has been 
deleted. It's now just "Request message framing is independent of method semantics, even if the 
method doesn't define any use for a message body" The 2nd quote "The GET method means retrieve 
whatever information ... is identified by the Request-URI" was deleted. - From a comment

https://stackoverflow.com/questions/978061/http-get-with-request-body

If these lines were deleted then there were reasons for this.

@heckad I read that SO before. If you dive into the comments of the most voted answer, you will see some good comments on this, eg: an opinion that ElasticSearch is the most used product that leveraging the body in GET request.
It's still not a widely accepted behavior. If you are building REST API for internal system, it's fine, since the GET can have syntactic sugar advantage.
But if you are working with the web browser, it's not compatible just yet for ajax clients, eg: https://github.com/rotki/rotki/issues/576
And a lot of HttpClient in other frameworks as well.

So let's push the industry towards a brighter future and create new products in which get methods will be used for queries.

Ps. Look at the dates.

OpenAPI is explicit about this: https://github.com/OAI/OpenAPI-Specification/blob/master/versions/3.0.2.md#operationObject and GET is not a method that takes bodies.

ElasticSearch is aware if its non-standard use of the GET method, that's why they also support POST. https://www.elastic.co/guide/en/elasticsearch/reference/current/search-request-body.html

Both HTTP GET and HTTP POST can be used to execute search with body. Since not all clients support GET with body, POST is allowed as well.

Assuming the original issue was solved, it will be automatically closed now. But feel free to add more comments or create new issues.

OpenAPI is explicit about this: https://github.com/OAI/OpenAPI-Specification/blob/master/versions/3.0.2.md#operationObject and GET is not a method that takes bodies.

It's allowed but not recommended. Look at https://github.com/OAI/OpenAPI-Specification/pull/2117/files

Ah! That's new, quite recent. :mag:

Although it's not yet in the OpenAPI versions released, it makes sense that FastAPI should support it. :heavy_check_mark:

I'll update the title and labels to reflect it.

working on this.

This was implemented by @victorphoenix3 in #1626 , so, receiving a body in a GET request is now supported although highly discouraged.

The generated OpenAPI includes the information of the body in the request, given it will be supported in the next OpenAPI releases.

Nevertheless, it is still not supported by Swagger UI, and I'm not sure they would want to support it. But still, you can now use it in FastAPI for those complex/specific use cases.

Available in FastAPI version 0.60.0. :tada: :rocket:

Assuming the original issue was solved, it will be automatically closed now. But feel free to add more comments or create new issues.

Was this page helpful?
0 / 5 - 0 ratings