Communicating with ElasticSearch

You can communicate with your ElasticSearch server with several protocols. In this recipe we will look at some main protocols.

Getting ready

You need a working ElasticSearch cluster.

How it works…

ElasticSearch is designed to be used as a RESTful server, so the main protocol is HTTP usually on port 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 one.

Every protocol has weak and strong points, 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 most standard and easy to use one.

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 it to communicate with Elasticsearch, the official clients switching from a protocol to another one is generally a simple setting in the client initialization. Refer to the following table which shows protocols and their advantages, disadvantages, and types:

Protocol	Advantages	Disadvantages	Type
HTTP	More often used. API safe and generally compatible with different ES versions. Suggested. JSON	HTTP overhead.	Text
Native	Fast network layer. Programmatic. Best for massive index operations.	API changes and breaks applications. Depends on the same version of ES server.	Binary
Thrift	As HTTP	Related to the thrift plugin.	Binary