28

Isn't it against REST-style approach to pass a request body together with GET request?

For instance to filter some information in Elasticsearch 

curl localhost:9200/megacorp/employee/_search -d '{"query" : {"filtered" : {"filter" : {"range" : {"age" : { "gt" : 30 }}},"query" : {"match" : {"last_name" : "smith"}}}}}'

some tools are even designed to avoid request body in GET request (like postman)

lospejos
  • 1,888
  • 3
  • 17
  • 31
yurko
  • 1,282
  • 1
  • 11
  • 14
  • See this answer which might help: http://stackoverflow.com/questions/34795053/es-keeps-returning-every-document/34796014#34796014 – Val Apr 29 '16 at 13:35
  • Detailed answer about GET and Body - https://stackoverflow.com/a/8502004/1589840 – serhiisavruk Jul 04 '17 at 10:21
  • @yurko how would you feel about changing your accepted answer? I worry that the accepted answer is going to mislead developers in the future to do the wrong thing. – Evert Jul 21 '18 at 17:37

3 Answers3

17

No. It's not.

In REST, using POST to query does not make sense. POST is supposed to modify the server. When searching you obviously don't modify the server.

GET applies here very well.

For example, what would be the difference of running a search with:

GET /_search?q=foo

vs

GET /_search
{
  "query": {
    "query_string": {
      "query" : "foo"
    }
  }
}

In both cases, you'd like to "GET" back some results. You don't mean to change any state on the server side.

That's why I think GET is totally applicable here wether you are passing the query within the URI or using a body.

That being said, we are aware that some languages and tools don't allow that. Although the RFC does not mention that you can't have a body with GET.

So elasticsearch supports also POST.

This:

curl -XPOST localhost:9200/megacorp/employee/_search -d '{"query" : {"filtered" : {"filter" : {"range" : {"age" : { "gt" : 30 }}},"query" : {"match" : {"last_name" : "smith"}}}}}'

Will work the same way.

dadoonet
  • 13,007
  • 2
  • 37
  • 46
  • 11
    If you claim that sending a get request with body is RESTful, so how do you explain [this](https://stackoverflow.com/a/983458/1057791)? – BornToCode Jun 29 '17 at 07:32
  • 6
    -1 That is why it's chaos with all this interpretation. If the semantics would be ignored, why would there be a need for so many request types. RESTful APIs should not take into consideration a body in their GET endpoints. Elastic stack is just hacky and not mature, alot of work to do on it (like most new open source projects, nothing wrong with that, time to make it better). If there was no body in GET, there was no need for a POST endpoint alternative ... This is why it's chaos, no conventions. I actually am for leaving the path in the url to decide, but REST was designed to use HTTP semanti – Geo C. Aug 01 '17 at 10:11
  • One HTTP request type to rule them all, the best way and most flexible in my opinion,and leave flexibility for those who implement and use the protocol , throught the url. this way there will be no obscurity with some endpoints (what exactly they are doing). I'm not really a fan of REST. I am a fan of simplicity & flexibility & of things that are easy to understand at the first sight – Geo C. Aug 01 '17 at 10:17
  • 1
    This answer is definitely incorrect. See my answer for sources. – Evert Jun 15 '18 at 07:37
  • except that Window.fetch does not allow a GET request to include a body – Zach Smith Mar 25 '20 at 14:57
  • That's why I said "So elasticsearch supports also POST." – dadoonet Mar 26 '20 at 15:06
16

From the RFC:

A payload within a GET request message has no defined semantics; sending a payload body on a GET request might cause some existing implementations to reject the request.

In other words, it's not forbidden, but it's undefined behavior and should be avoided. HTTP clients, servers and proxies are free to drop the body and this would not go against the standard. It's absolutely a bad practice.

Further text from the HTTPBis working group (the group working on HTTP and related standards):

Finally, note that while HTTP allows GET requests to have a body syntactically, this is done only to allow parsers to be generic; as per RFC7231, Section 4.3.1, a body on a GET has no meaning, and will be either ignored or rejected by generic HTTP software.

source

Evert
  • 75,014
  • 17
  • 95
  • 156
  • Is GET _search?q=foo correct? Yes. Then why would you change the semantic when you want to pass foo as a json body? It's a search call for both at the end. I'm not posting something to the server to change its state. I'm just requesting something from the server, whatever the way I'm passing parameters. – dadoonet Jun 15 '18 at 09:40
  • 1
    @dadoonet because the appearance of a body with GET, while not 'invalid' should not have a semantic meaning to the request. In other words, it should be ignored. Whether or not you agree with this, this is absolutely the intent of the protocol. – Evert Jun 15 '18 at 17:44
  • 1
    I could go into details why I think this is a actually good design, but I think for the purpose of this discussion it's better to stick to the raw facts. The HTTP working group clearly states that generic HTTP software will ignore or reject bodies. Therefore, elasticsearch's implementation relies on non standard behavior. Any compliant HTTP proxies and caches will misbehave in conjunction with elasticache because they tend to be compliant. – Evert Jun 15 '18 at 17:50
1

you can use query parameter in elasticsearch get request just add source=query_string_body & source_content_type='application/json'

the url will like following

http://localhost:9200/index/_search/?source_content_type=application/json&source={"query":{"match_all":{}}}

ref: https://discuss.elastic.co/t/query-elasticsearch-from-browser-webservice/129697

王信凱
  • 183
  • 1
  • 7