There are various following methods which is available…
- Java REST Client
- Java API
- Groovy API
- .NET API
- PHP API
- Perl API
- Python API
- Ruby API
- Community Contributed Clients
Details can be found here.
RESTful API with JSON over HTTPedit
All other languages can communicate with Elasticsearch over port 9200 using a RESTful API, accessible with your favorite web client.
A request to Elasticsearch consists of the same parts as any HTTP request:
[code]curl -X<VERB> ‘<PROTOCOL>://<HOST>:<PORT>/<PATH>?<QUERY_STRING>’ -d ‘<BODY>'[/code]
The parts marked with < > above are:
|VERB||The appropriate HTTP method or verb: GET, POST, PUT, HEAD, or DELETE.|
|PROTOCOL||Either http or https (if you have an https proxy in front of Elasticsearch.)|
|HOST||The hostname of any node in your Elasticsearch cluster, or localhost for a node on your local machine.|
|PORT||The port running the Elasticsearch HTTP service, which defaults to 9200.|
|PATH||API Endpoint (for example _count will return the number of documents in the cluster). Path may contain multiple components, such as _cluster/stats or _nodes/stats/jvm|
|QUERY_STRING||Any optional query-string parameters (for example ?pretty will pretty-print the JSON response to make it easier to read.)|
|BODY||A JSON-encoded request body (if the request needs one.)|
In case of Java based, Elasticsearch has been deleloped using Java so Elasticsearch comes with two built-in clients that you can use in your code:
The node client joins a local cluster as a non data node. In other words, it doesn’t hold any data itself, but it knows what data lives on which node in the cluster, and can forward requests directly to the correct node.
The lighter-weight transport client can be used to send requests to a remote cluster. It doesn’t join the cluster itself, but simply forwards requests to a node in the cluster.
Both Java clients talk to the cluster over port 9300, using the native Elasticsearch transport protocol. The nodes in the cluster also communicate with each other over port 9300. If this port is not open, your nodes will not be able to form a cluster.
Difference between Transport client Vs Node client
The transport client acts as a communication layer between the cluster and your application. It knows the API and can automatically round-robin between nodes, sniff the cluster for you, and more. But it is external to the cluster, similar to the REST clients.
The node client, on the other hand, is actually a node within the cluster (but does not hold data, and cannot become master). Because it is a node, it knows the entire cluster state (where all the nodes reside, which shards live in which nodes, and so forth). This means it can execute APIs with one less network hop.
Uses-cases for Transport client and Node client
The transport client is ideal if you want to decouple your application from the cluster. For example, if your application quickly creates and destroys connections to the cluster,a transport client is much “lighter” than a node client, since it is not part of a cluster.
Similarly, if you need to create thousands of connections, you don’t want to have thousands of node clients join the cluster. The TC will be a better choice.
On the flipside, if you need only a few long-lived, persistent connection objects to the cluster, a node client can be a bit more efficient since it knows the cluster layout. But it ties your application into the cluster, so it may pose problems from a firewall perspective.
Good Read can be found here as well
Elasticsearch transport client example
Elasticsearch node client example