Communicating with ElasticSearch

You can communicate with several protocols using your ElasticSearch server. In this recipe, we will take a look at the main protocols.

Getting ready

You will need a working instance of the ElasticSearch cluster.

How it works...

ElasticSearch is designed to be used as a RESTful server, so the main protocol is the HTTP, usually on port number 9200 and above. Thus, it allows using different protocols such as native and thrift ones.

Many others are available as extension plugins, but they are seldom used, such as memcached, couchbase, and websocket. (If you need to find more on the transport layer, simply type in Elasticsearch transport on the GitHub website to search.)

Every protocol has advantages and disadvantages. It's important to choose the correct one depending on the kind of applications you are developing. If you are in doubt, choose the HTTP Protocol layer that is the standard protocol and is easy to use.

Choosing the right protocol depends on several factors, mainly architectural and performance related. This schema factorizes advantages and disadvantages related to them. If you are using any of the protocols to communicate with ElasticSearch official clients, switching from a protocol to another is generally a simple setting in the client initialization.

Protocol	Advantages	Disadvantages	Type
HTTP	Frequently used API is safe and has general compatibility for different versions of ES, although JSON is suggested	HTTP overhead	Text
Native	Fast network layer Programmatic Best for massive indexing operations	If the API changes, it can break the applications Requires the same version of the ES server Only on JVM	Binary
Thrift	Similar to HTTP	Related to the Thrift plugin	Binary