Describe the feature:
Support for setting url query paramters within the RequestOptions object
Recently I came to a point where I wanted a smaller search response. The reason why I wanted it was because of network latency, big search responses and not needed fields within the search response. By discarding specific fields the response would be smaller measured in kb.
This option is unfortunately not possible with the RestHighLevelClient and also not possible to add as a property to a SearchRequest. And adding that option to the SearchRequest would mean a change for the specification of the SearchRequest. But I have the feeling that something like that is not a part of the search request.
If we grab an example which I have used at kibana, it would look like this:
GET twitter/_search?filter_path=-hits.hits._index
{
"query": {
"match_all": {}
}
}
Lets translate this request to a basic search request with the RestHighLevelClient (without filter path):
RestClientBuilder clientBuilder = RestClient.builder(new HttpHost("localhost", 9200));
RestHighLevelClient client = new RestHighLevelClient(clientBuilder);
SearchRequest searchRequest = new SearchRequest();
SearchSourceBuilder sourceBuilder = new SearchSourceBuilder()
.query(new MatchAllQueryBuilder());
searchRequest.source(sourceBuilder)
.indices("twitter");
SearchResponse response = client.search(searchRequest, RequestOptions.DEFAULT);
Let's translate this request to a request to execute with the LowLevelClient including filter_path while preserving the capability of sending a SearchRequest and getting back a SearchResponse
RestClientBuilder clientBuilder = RestClient.builder(new HttpHost("localhost", 9200));
RestHighLevelClient client = new RestHighLevelClient(clientBuilder);
SearchRequest searchRequest = new SearchRequest();
SearchSourceBuilder sourceBuilder = new SearchSourceBuilder()
.query(new MatchAllQueryBuilder());
searchRequest.source(sourceBuilder)
.indices("twitter");
Request request = new Request(HttpPost.METHOD_NAME, "/" + String.join(",", searchRequest.indices()) + "/_search");
request.setOptions(RequestOptions.DEFAULT);
request.addParameter("filter_path","-hits.hits._index");
HttpEntity httpEntity = new NStringEntity(searchRequest.source().toString(), ContentType.APPLICATION_JSON);
request.setEntity(httpEntity);
Response response = client.getLowLevelClient().performRequest(request)
List<NamedXContentRegistry.Entry> entries = new ArrayList<>();
entries.add(new NamedXContentRegistry.Entry(Aggregation.class, new ParseField(StringTerms.NAME), (parser, content) -> ParsedStringTerms.fromXContent(parser, (String) content)));
entries.add(new NamedXContentRegistry.Entry(Aggregation.class, new ParseField(TopHitsAggregationBuilder.NAME), (parser, content) -> ParsedTopHits.fromXContent(parser, (String) content)));
entries.add(new NamedXContentRegistry.Entry(Suggest.Suggestion.class, new ParseField("term"), (parser, content) -> TermSuggestion.fromXContent(parser, (String) content)));
entries.add(new NamedXContentRegistry.Entry(Suggest.Suggestion.class, new ParseField("phrase"), (parser, content) -> PhraseSuggestion.fromXContent(parser, (String) content)));
NamedXContentRegistry namedXContentRegistry = new NamedXContentRegistry(entries);
String content = EntityUtils.toString(response.getEntity());
XContentParser parser = JsonXContent.jsonXContent.createParser(namedXContentRegistry, null, content);
SearchResponse searchResponse = SearchResponse.fromXContent(parser);
This would return me all documents from the twitter index without the index name within the hits.
As you can see there is a lot code needed to just use the filter_path while maintaining the SearchRequest and SearchResponse at a highlevel of our code base.
It would be great if there would be support or a new feature to enable RequestOptions to also support query parameter. Now the RequestOptions just only supports headers. Request options with query parameters could look like this:
RequestOptions.DEFAULT.toBuilder()
.addParameter("filter_path","-hits.hits._index");
Describe the feature:
Support for setting url query paramters within the RequestOptions object
Recently I came to a point where I wanted a smaller search response. The reason why I wanted it was because of network latency, big search responses and not needed fields within the search response. By discarding specific fields the response would be smaller measured in kb.
This option is unfortunately not possible with the RestHighLevelClient and also not possible to add as a property to a SearchRequest. And adding that option to the SearchRequest would mean a change for the specification of the SearchRequest. But I have the feeling that something like that is not a part of the search request.
If we grab an example which I have used at kibana, it would look like this:
Lets translate this request to a basic search request with the RestHighLevelClient (without filter path):
Let's translate this request to a request to execute with the LowLevelClient including filter_path while preserving the capability of sending a SearchRequest and getting back a SearchResponse
This would return me all documents from the twitter index without the index name within the hits.
As you can see there is a lot code needed to just use the filter_path while maintaining the SearchRequest and SearchResponse at a highlevel of our code base.
It would be great if there would be support or a new feature to enable RequestOptions to also support query parameter. Now the RequestOptions just only supports headers. Request options with query parameters could look like this: