There are two main ways of querying data in Elasticsearch. The URI Search is simple and convenient, and the Query DSL is verbose but powerful. In this post, we'll look at the pros and cons of each, and I'll tell you why you should just stick to the Query DSL.
Here is a sample URI Search that is querying for podcasts with the title of "Coding Blocks":
# URI Search version
GET /podcasts/_search?q=title:"Coding Blocks"
As a human being (really, I assure you - why would you even think otherwise? Don't worry about it!) I find this request easy on the eyes and the fingers.
The Query DSL version of this query isn't so bad really but it does involve quite a few brackets, and you need to know a bit more about how the API works in order to write it:
# Query DSL version
GET /podcasts/_search
{
"query": {
"match": {
"title": "Coding Blocks"
}
}
}
What happens if you need to make a change? Say, I want to check for podcasts titled either "Coding Blocks" or "MS Dev Show"?
Again, the URI Search is dead simple:
# URI Search version
GET /podcasts/_search?q=title:"Coding Blocks" OR title:"MS Dev Show"
But the Query DSL version has morphed. In addition to sprouting new brackets, you also have to introduce some additional property nesting. Yikes!
# Query DSL version
GET /podcasts/_search
{
"query": {
"bool": {
"should": [
{
"match": {
"title": "Coding Blocks"
}
},
{
"match": {
"title": "MS Dev Show"
}
}
]
}
}
}
So what's good about the Query URI version? It's simple and eloquent for simple and eloquent queries. It's quite powerful too, it supports all the same advanced features as the Query String Query and there are even 18 other parameters you can pass to fine tune your results.
Not too shabby, but...
Here's a list of reasons I came up with for you to avoid using the URI search for anything but the laziest of curls.
As your queries get more advanced, the URI Search doesn't hold up very well. The syntax that's so simple and eloquent to begin with eventually starts to get harder and harder to read as you add conditions...and lets not forget what those 18 parameters would look like if you actually set them all.
More importantly, there are things you just can't do in the URI Search. The Elasticsearch query API is full of advanced features, like aggregations, and scripting, and Geo fencing that you just can't do.
Tools like Kibana or libraries like Nest take advantage of the rigid-ish structure of json to offer nice intellisense and strong-ish typing around the Elastic API that help protect you from mistakes and ultimately save time. The URI Search skirks these rules, so these tools aren't available
That's fine. Ultimately I think it's more valuable to start with, and stay with, the Query DSL. If you prefer the terse syntax and expressiveness of the Query String, and you've made your piece with the fact that you may have to rewrite that query then I wish you the best of luck.
Good luck.