Since you are planning on using a GUI, drop-downs, etc to construct the query I'd personally use the rest of the query DSL and avoid Query String. E.g. construct a
bool query, and each time the user adds a new query condition, add a new
match query to the
bool clauses. Etc etc.
This will give you control over what is being executed, and most importantly, allow you to restrict what the user can search. Essentially, you are converting the GUI dropdowns into query dsl components and combining them in different boolean combinations.
query_string is an option, but it's more designed for "single line" queries. E.g. when you want to express a full boolean query with multiple components, all in a single string on a single line.
The downside to Query String is the power: it expects the user to A) know the syntax and B) exposes all the query functionality to the user. So there's nothing stopping a user from specifying very bad queries, like leading wildcards (
*foo) or excessive fuzzy queries. QueryString is mainly for "power users" that need a single line query syntax.
There is also
simple_query_string, which provides some of the same advanced features (boolean logic, etc) but is a bit "safer" in that it restricts what can be used.
But yeah, since you're already overlaying a GUI on the DSL, I'd just use boolean queries with match queries for most of it