So I can successfully do request like:
localhost:9200/filebeat-*/_count?filter_path=-_shards
{"query": {
"match_phrase" : {
"message" : "o hohoho"
}
}}
How I can move filter_path=-_shards into the request body to make it work?
According to the documentation code, still not possible in Elasticsearch 6.2:
All REST APIs accept a filter_path parameter that can be used to
reduce the response returned by Elasticsearch
and it's impossible to include it into the request body, that's just not supported (to be honest, I'm not sure if it will ever be supported).
However, for some scenarios, you could limit response returned by Elasticsearch by using source filtering (unfortunately, it's only applicable to returned fields of documents)
Related
I use google-drive-api from this link.
But I find my response is different from the api website.
My response:
{
"kind": "drive#file",
"id": "1hs6V6eDa6CYd3gtkAeRKlrOezLYpDWTfWh5VFtchFYA",
"name": "Test001",
"mimeType": "application/vnd.google-apps.spreadsheet"
}
You can see it:
But the documented file response object is very detailed.
Why are these two response results different?
Normally by default, the server sends back the full representation of a resource after processing requests. For better performance, you can ask the server to send only the fields you really need and get a partial response instead.
Google Drive api v3 has partial response enabled for most of the methods by default. To request a partial response, use the fields request parameter to specify the fields you want returned. You can use this parameter with any request that returns response data.
Example:
returns only Kind, items.title,
&fields=kind,items(title)
or
Returns everything
&fields=*
Tip: In the try me click Show standard parameters you will be able to add fields
Like at this elastic get query I see below example where per my understanding query_string is passed under request body in GET request . Is n't it ? But I believe we can't pass request body with GET request then how come this example is true ?
GET /_search
{
"query": {
"query_string" : {
"default_field" : "content",
"query" : "this AND that OR thus"
}
}
}
In fact when I used the option COPY as CURL from the stated link I see below copied text
curl -X GET "localhost:9200/_search" -H 'Content-Type: application/json' -d'
{
"query": {
"query_string" : {
"default_field" : "content",
"query" : "this AND that OR thus"
}
}
}
'
Am I missing anything here or something wrong in example? In fact I do not see the way to send the request body under Postman tool.
The fact is that you can send a GET request with a body. The current HTTP standard rfc7231 (obsoletes rfc2616 and updates rfc2817) does not strictly define what must happen to a GET request with a body. The previous versions were different in this regard. For that reason, some HTTP servers allow it, but some others don't, I'm afraid. This case is mentioned in the latest standard as follows:
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 terms of Elasticsearch, using using GET for a search request is a design decision. They feel it makes more sense semantically. Because it represents a data retrieving action better than the POST verb.
On the other hand, as mentioned above, a GET request with a body is not supported universally. That's why Postman does not allow you to do so, although Kibana > Dev Tool does it by using cURL. Therefore, the Elasticsearch search API also supports POST requests to search and retrieve information. So, when you cannot make a GET request with a body, you can obtain exactly the same result by making a POST request.
This is actually very interested question. In fact, a lot of HTTP clients aren’t supporting GET requests with body (i just recently face, that iOS client in Cocoa isn’t able to do so).
I also had a lot of discussions with my colleagues - to me after using Elasticsearch for a long time GET with a body sounds like a perfectly fine HTTP request, however some may argue, that GET shouldn’t go with body at all according to HTTP standard. However, I will leave this discussion out of this answer.
In general this leads to a situation, that if you’re using client which not supporting GET, you could either change it to POST or switch to something else - I used to use cURL all the time or Kibana Dev Tools if I needed to construct complex query on the fly
Recently I use Kibana console to update a field of an existing document in ElasticSearch, I saw this error while using the PUT method for this, which confuse me a lot.
{
"error": "Incorrect HTTP method for uri [/product/_doc/1/_update] and method [PUT], allowed: [POST]",
"status": 405
}
The query I used is
PUT /product/_doc/1/_update
{
"doc": {"price": 95, "tags": ["Elasticsearch"]}
}
Which I believe should be idempotent. Could someone help me understand why only POST method can be used here? My thinking is PUT method is for idempotent operations so to me, PUT should be the only candidate rather than POST.
Depending on how you read the semantics of HTTP a PUT would replace a resource entirely and you would need a PATCH for an update (which isn't supported by Elasticsearch). Also the _update endpoint will either accept doc or script and the later one isn't necessarily idempotent — for example doing a scripted upsert.
Generally Elasticsearch is as RESTful as possible, but will make pragmatic choices where required.
Here is my JSON .
{
"id":100,
"name":"xxx",
"hobbies":["cricket","footbal","singing & dancing"]
}
I need to filter "singing & dancing" string from "others". Executed below query.
http://localhost:9200/employeed/data/_search?q={"query":{"query_string":{"query" : "hobbies:Singing & dancing"}}}
I am getting below exception.
"type": "illegal_argument_exception",
"reason": "request [employee/data/_search] contains unrecognized parameter: [ Singing\"}}}]"
Any help?
You're attempting to send a DSL query in a URI. The two don't mix, see here: https://www.elastic.co/guide/en/elasticsearch/reference/6.2/search-search.html
The search API allows you to execute a search query and get back search hits that match the query. The query can either be provided using a simple query string as a parameter, or using a request body.
You can either use the DSL and send it in your request body, or change your URL to just include the hobbies query_string you want to use. Like this:
http://localhost:9200/employeed/data/_search?q=hobbies%3A%5C%22Singing%20%26%20dancing%5C%22
The query_string portion is also URL encoded. I've also added quotes around your search value, otherwise it will OR them together. The unencoded version:
hobbies:\"Singing & dancing\"
The official reference states that one can send _search requests also through POST instead of GET because not all clients support sending bodys with GET (see https://www.elastic.co/guide/en/elasticsearch/reference/current/search-request-body.html). You can then insert the query parameters from the URL also as JSON directly in the body.
Now I wonder: is this true for all GET requests that Elasticsearch offers that need query parameters?
For example, the _stat endpoint (https://www.elastic.co/guide/en/elasticsearch/reference/current/indices-stats.html) is documented as a GET request (which makes sense), but supports URI parameters. Is it safe to use POST in this case as well and pass the parameters in the body using JSON?
No, the _search endpoint is one of a few special cases. If you look at the source code for the _stats endpoint in RestIndicesStatsAction.java, you can see that only the GET HTTP method is supported.
Using the POST method usually makes sense only when the payload to be sent can be substantially big, which is not the case for the few parameters such as the ones accepted by the _stats endpoint. In that case, sending those parameters in the query string is usually more than sufficient.