Issue 1:
AFAIK, it would be great if two types of interfaces are defined, which would help developers to do better source reusing. And also that there maybe other things in same situation, I hope somebody else can commit them here too.

At first, for the request builders, there are SearchRequestBuilder, CountRequestBuilder and DeleteByQueryRequestBuilder which are sharing a group of methods with same name due to the completely same functions. Thus, currently, I have to define 3 methods for the separated 3 types if I want to add some common search define on the request(especially for adding routing by common logic).

Secondly, for the QueryBuilders and FilterBuilders, they are in 99% similarity logically and they are in 99% similarity in the real source but there are only separated interfaces for each other of query and filter. Hence, I have to define 2 methods for the separated 2 types if I want to create a common query define for some common business data structure.

I believe both of the above situations can be addressed by defining higher level interfaces.

Issue 2:
Copied from #9901:

Today we have a massive infrastructure to parse all our requests. We have client side builders and server side parsers but no real representation of the query, filter, aggregation etc until it's executed. What is produced from a XContent binary is a Lucene query directly which causes huge parse methods in separate classes etc. that hare hard to test and don't allow decoupled modifications or actions on the query itself between parsing and executing.

This refactoring splits the parsing and the creation of the lucene query, this has a couple of advantages

XContent parsing creation are in one file and can be tested more easily

the class allows a typed in-memory representation of the query that can be modified before a lucene query is build

the query can be normalized and serialized via Streamable to be used as a normalized cache key (not depending on the order of the keys in the XContent)

the query can be parsed on the coordinating node to allow document prefetching etc. forwarding to the executing nodes would work via Streamable binary representation --> #8150

for the query cache a query tree can be "walked" to rewrite range queries into match all queries with MIN/MAX terms to get cache hits for sliding windows --> #9526

code wise two classes are merged into one which is nice

Queries (Completed)

AndQueryBuilder (#11628)

BoolQueryBuilder (#11121)

BoostingQueryBuilder (#11621)

CommonTermsQueryBuilder (#11345)

ConstantScoreQueryBuilder (#11629)

DisMaxQueryBuilder (#11703)

ExistsQueryBuilder (#11427)

FieldMaskingSpanQueryBuilder (#11717)

FilteredQueryBuilder (#11885)

FQueryFilterBuilder (#11729)

FunctionScoreQueryBuilder (#13653)

FuzzyQueryBuilder (#11865)

GeoBoundingBoxQueryBuilder (#11969)

GeoDistanceQueryBuilder(#13496)

GeoDistanceRangeQueryBuilder (#13496)

GeohashCellQuery (#13393)

GeoPolygonQueryBuilder (#13426)

GeoShapeQueryBuilder (#13466)

HasChildQueryBuilder (#13333)

HasParentQueryBuilder (#13408)

IdsQueryBuilder (#10670)

IndicesQueryBuilder (#12031)

LimitQueryBuilder (#11551)

MatchAllQueryBuilder (#10668)

MatchQueryBuilder (#13402)

MissingQueryBuilder (#12030)

MoreLikeThisQueryBuilder (#13486)

MultiMatchQueryBuilder (#13405)

NestedQueryBuilder (#13424)

NotQueryBuilder (#11823)

OrQueryBuilder (#11817)

PrefixQueryBuilder (#12032)

QueryFilterBuilder (#11729)

QueryStringQueryBuilder (#13284)

QueryWrappingQueryBuilder (will be removed once all queries refactored)

RangeQueryBuilder (#11108)

RegexpQueryBuilder (#11896)

ScriptQueryBuilder (#12115)

SimpleQueryStringBuilder (#11274)

SpanContainingQueryBuilder (#12057)

SpanFirstQueryBuilder (#12073)

SpanMultiTermQueryBuilder (#12182)

SpanNearQueryBuilder (#12156)

SpanNotQueryBuilder (#12365)

SpanOrQueryBuilder (#12342)

SpanTermQueryBuilder (#11005)

SpanWithinQueryBuilder (#12396)

TemplateQueryBuilder (#13253)

TermQueryBuilder (#10669)

TermsLookupQueryBuilder (#12042)

TermsQueryBuilder (#12042)

TypeQueryBuilder (#12035)

WildcardQueryBuilder (#12110)

WrapperQueryBuilder (#12037)

Total of 54 Queries

54 done

Former filters were mostly merged or converted to queries and are included in this list.

Aggregations (Completed - #14136)

Min Aggregation (#12832)

Max Aggregation (#14687)

Sum Aggregation (#14687)

Avg Aggregation (#14687)

Stats Aggregation (#14688)

Extended Stats Aggregation (#14688)

Value Count Aggregation (#14689)

Percentiles Aggregation (#14836)

Percentile Ranks Aggregation (#14836)

Cardinality Aggregation (#14893)

Geo Bounds Aggregation (#14934)

Top hits Aggregation (#15566)

Scripted Metric Aggregation (#14966)

Global Aggregation (#14139)

Filter Aggregation (#14974)

Filters Aggregation (#15437)

Missing Aggregation (#14975)

Nested Aggregation (#15006)

Reverse nested Aggregation (#15006)

Children Aggregation (#15008)

Terms Aggregation (#15386)

Significant Terms Aggregation (#15386)

Sampler Aggregation (#15418)

Range Aggregation (#15399)

Date Range Aggregation (#15399)

IPv4 Range Aggregation (#15399)

Histogram Aggregation (#14140)

Date Histogram Aggregation (#14140)

Geo Distance Aggregation (#15399)

GeoHash grid Aggregation (#14138)

Geo Centroid Aggregation (#15002)

Min Bucket Aggregation (#15009)

Max Bucket Aggregation (#15009)

Avg Bucket Aggregation (#15009)

Sum Bucket Aggregation (#15009)

Stats Bucket Aggregation (#15009)

Extended Stats Bucket Aggregation (#15009)

Percentiles Bucket Aggregation (#15009)

Bucket Script Aggregation (#15014)

Cumulative Sum Aggregation (#15015)

Derivative Aggregation (#14137)

Bucket Selector Aggregation (#15147)

Moving Average Aggregation (#15180)

Serial Differencing Aggregation (#15058)

Total of 44 Aggregations

44 done

Suggesters

Term suggester

Phrase Suggester

Completion Suggester

Context Suggester

Total of 4 Suggesters

4 done, 0 in open PRs

Highlighters

plain

fvh

postings

Total of 3 Highlighters

3 done

Others

from (#13752)

size (#13752)

min_score (#13752)

fields (#13752)

script_fields (#13752)

fielddata_fields (#13752)

_source (#13752)

sort (#17205)

timeout (#13752)

explain (#13752)

terminate_after (#13752)

version (#13752)

stats (#13752)

indices_boost (#13752)

track_scores (#13752)

inner_hits (#17291)

query_binary: (removed, queries should only be specified via type-safe builders in the Java API, see #14308)

filter_binary: (removed, filters should only be specified via type-safe builders in the Java API, see #14308)

aggregations_binary: (to be removed, aggregations should only be specified via type-safe builders in the Java API, see #14308 and #14136)

rescore (#15559)

post_filter (#13752)

APIs to be adapted/revised besides _search

search exists api (removed, see #13911)

explain api: (#14270)

validate query api: (#14384)

suggest api (#17198)

percolator (Planned to be removed, see #16349)

index warmers (removed, see #15614)

alias filters

The above apis don't necessarily have to change to parse queries in our intermediate format, for instance the percolator will still need to parse to lucene query straight-away, but we should still have a look at each of those and double check if anything needs to be adjusted after all the infra changes we have made.