I would like to run an elasticsearch query to find items within 10mi of a given point.
I know how to do it with a post, but I would like to use a get with everything in the uri.
I found the below example but it does not work.
http://localhost:9200/items/item/_search?{%22query%22:{%22filtered%22:{%22query%22:{%22match_all%22:{}},%22filter%22:{%22geo_distance%22:{%22distance%22:%220.1km%22,%22location%22:{%22lat%22:46.884106,%22lon%22:-71.377042}}}}}}
Any way to do this or am I stuck using a post?
The key is the source= parameter. Not to be confused with _source.
http://localhost:9200/items/item/_search?source={%22query%22:{%22filtered%22:{%22query%22:{%22match_all%22:{}},%22filter%22:{%22geo_distance%22:{%22distance%22:%220.1km%22,%22location%22:{%22lat%22:46.884106,%22lon%22:-71.377042}}}}}}
I had tried ?q= and a few other parameters listed on http://www.elasticsearch.org/guide/reference/api/search/uri-request/ with no luck (source is not listed).
I found http://www.elasticsearch.org/guide/reference/api/ and at the very bottom it says
request body in query string
For libraries that don’t accept a request body for non-POST requests,
you can pass the request body as the source query string parameter
instead.
So structure your query/filter request, set it all on one line and send it into the source parameter.
Do not use the q= parameter with source= or it will conflict and break the query, however I tried size= and from= and they work with source just fine.
Related
I'm new to the elastic-cloud interface. It allows to chooose operations get, post, put and del. I'm trying to submit queries, but I don't know the precise syntax. For instance:
tweet/_search?q=something
works, but:
tweet/_search?q={ "match_all": {} }
does not, returning a parser error. I have tried with double quotes, but it seems that then it searches for the query as a string.
The preferred way to test the search APIs are using the POST method, GET API in some case, gives even incorrect search results as it ignores the search and brings the top 10 search results for match_all query.
Elasticsearch supports both methods GET and POST to search but using the GET method which has payload information isn't common on modern app-severs, although Elasticsearch implemented it requires carefully crafting your queries.
Still, if you want to use the GET API, then for complex queries its better to send it as part of request body, I know it sounds weird to send a body to GET request but it works 😀 .
I'm trying to use Spring's ServletUriComponentsBuilder to create paging next and prev links from the current request.
The problem I'm having is that the ServletUriComponentsBuilder.fromCurrentRequest() is not unencoding percent-encoded values like:
http://example.com/articles?page%5Bnumber%5D=2
The problem is uses could have called the page with unencoded square brackets like http://example.com/articles?page[number]=2 without any problems.
Spring Data is accepting both variants (both unencoded square brackets and encoded square brackets) in it's pageable argument resolver.
This to the fact that under water the Coyote web request get parameter is used which contains the unencoded param names.
Also Spring's #RequestParam("page[number]") accepts without any problem the encoded request like http://example.com/articles?page%5Bnumber%5D=2.
From the server side I always want to return percent encoded url's as per RFC 3986.
But there does not seem a way to this as the UriComponents query params might contain both encoded en uncoded names. Because to that, if I would call encode() on the builder the already encoded query params get encoded another time, but if would contain unencoded names toURI() will fail as an unencoded [ is not allowed.
Note that the url's might contain multiple query params besides paging, e.g. for filtering.
A request could come in like:
http://example.com/articles?filter[category]=food
And would return a response with a encoded next link like:
http://example.com/articles?page%5Bnumber%5D=2&filter%5Bcategory%5D=food
My workaround it to ignore ServletUriComponentsBuilder and simply get the request url and do so custom regexp replacing.
I know this is an older question and you also found a workaround. But did you try to use ServletUriComponentsBuilder's build() method?
Some kind of the following:
ServletUriComponentsBuilder.fromCurrentRequest().build().toUriString();
I had some issues when handling JSON Strings and this helped.
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.
We use the Result format (from the Search Protocol) for our results page (we manually parse the XML responds). We wishes now to switch to the Dynamic Result Clusters format. The only problem is that spelling suggestion (Related Queries) doesn't seem to be available using that protocol.
The only solution I seem to find is to:
First do a /clusters... request. If the request return no result...
...to another request to /search... to see if that request would return a spelling suggestion (Related Queries).
Am I missing something? Can the Clusters format return also spelling suggestion?
Got it.
/clusters request are not to be use instead of the /search request.
You must :
First, do a normal /search request.
Then, do a AJAX request to /clusters to produce the suggestion.
So you keep all the features of the /search request (KeyMatches, Related Queries, etc).
I'd like to be able to document the parameters as if they were URL parameters, since I like how that bit of documentation renders a handy table. However, in my API, I would like those paremeters to plug into the JSON body rather than the URL. Is there a way to achieve this?
The dedicated syntax for describing, discussing (and thus also validating) message-body is in the making.
It will be based on the Markdown Syntax for Object Notation, similar to the actual URI Parameters description syntax (eventually these two should converge).
Also see related How to specify an optional element for a json request object and Is it possible to document what JSON response fields are? questions.