search_exists should be consistent with other *_exists methods

[honzakral]

• use HEAD request type (which also means to allow for POST when http client cannot send HEAD with body, as well as the source parameter)
• the client API should only return true/false
• the yaml tests need to be changed to reflect that

[nik9000]

Any reason not to have a HEAD request for a SEARCH default to search_exists? Maybe its just too weird do a HEAD with a body.

By the client API do you mean the Java api? All of them?

[honzakral]

Unfortunately we cannot rely on HEAD working with body, the specs allow for it, but many clients and proxies don't so we need to be cautious and have a separate endpoint just to be sure.

I mean all of them, they should be consistent in this, but those will be updated once the java client is and the yaml test suite is changed to reflect that.

[javanna]

Search exists api is different compared to search. Search (as well as count) does allow you to set terminate_after, but it will still go to each of the shard in the context of the search request and execute the query there, the terminate_after is effectively per shard. Search exists returns the response after the first shard reports existing documents, instead of blocking for responses from all the shards. This is the main reason why this is a separate endpoint I think.

Supporting HEAD for consistency sounds good but this api is different compared to other exists* api, as it has to accept a body (which can be provided as query_string encoded source parameter too though to work around any potential proxy/client issue).

[javanna]

@honzakral I didn't notice at first your point around supporting POST too, makes perfect sense. +1

[s1monw]

yeah lets do it - I think this is relatively simple to add. We have org.elasticsearch.rest.action.exists.RestExistsAction that is registered in org.elasticsearch.rest.action.search.RestSearchAction but only for GET and POST. If we register it for HEAD as well as omit the response it does when it is a HEAD request we are good to go?

For the response part I think we can just omit the response if we request.method() == RestRequest.Method.HEAD

[s1monw]

I know @markharwood mentioned that @ESamir was looking for a low hanging fruit, this one could be one?

[javanna]

I marked this back for discussion. The search/exists api has been removed from master and deprecated in 2.1. We can now discuss whether we want _search to work with HEAD or not. It currently doesn't. Seems like a different endpoint than _search would still be required for the reasons stated by @honzakral above though. And it would be the first api that responds to HEAD but accepts a body, which many clients don't support.

[clintongormley]

And it would be the first api that responds to HEAD but accepts a body, which many clients don't support.

If it is going to be part of the Elasticearch API, then it needs to be part of the REST tests, which means that all clients should be able to support it. This makes me lean towards: if you want to add a shortcut to a particular client then go for it, but it shouldn't be part of the official API.

[clintongormley]

Search exists has been removed. Closing