Elasticsearch连接支持2种协议，http协议和Native Elasticsearch binary protocol（本地elasticsearch二进制协议）。还可以通过使用插件来扩展支持的协议。有一些官方的插件。java之外的语言不推荐使用第二种方式，因为第二种方式需要很多自定义序列化。
基于HTTP协议，以JSON为数据交互格式的RESTful API
其他所有程序语言都可以使用RESTful API，通过9200端口的与Elasticsearch进行通信，你可以使用你喜欢的WEB客户端，事实上，如你所见，你甚至可以通过curl命令与Elasticsearch通信。
Elasticsearch官方提供了多种程序语言的客户端——Groovy，Javascript，.NET，PHP，Perl，Python，以及 Ruby——还有很多由社区提供的客户端和插件，所有这些可以在文档中找到。
向Elasticsearch发出的请求的组成部分与其它普通的HTTP请求是一样的：
curl -X<VERB> '<PROTOCOL>://<HOST>:<PORT>/<PATH>?<QUERY_STRING>' -d '<BODY>'
- VERB HTTP方法：GET, POST, PUT, HEAD, DELETE
- PROTOCOL：http或者https协议（只有在Elasticsearch前面有https代理的时候可用）
- HOST：Elasticsearch集群中的任何一个节点的主机名，如果是在本地的节点，那么就叫localhost
- PORT：Elasticsearch HTTP服务所在的端口，默认为9200 PATH API路径（例如_count将返回集群中文档的数量），
- PATH：可以包含多个组件，例如_cluster/stats或者_nodes/stats/jvm
- QUERY_STRING：一些可选的查询请求参数，例如?pretty参数将使请求返回更加美观易读的JSON数据
- BODY：一个JSON格式的请求主体（如果请求需要的话）
举例说明，为了计算集群中的文档数量，我们可以这样做：
curl -XGET 'http://localhost:9200/_count?pretty' -d '
{
"query": {
"match_all": {}
}
}
'
Elasticsearch返回一个类似200 OK的HTTP状态码和JSON格式的响应主体（除了HEAD请求）。上面的请求会得到如下的JSON格式的响应主体：
{
"count": 0,
"_shards": {
"total": 5,
"successful": 5,
"failed": 0
}
}
Java API
Elasticsearch为Java用户提供了两种内置客户端。
传输客户端（Transport client）
这个轻量的传输客户端能够发送请求到远程集群。它自己不加入集群，只是简单转发请求给集群中的节点。
两个Java客户端都通过9300端口与集群交互，使用Elasticsearch传输协议(Elasticsearch Transport Protocol)。集群中的节点之间也通过9300端口进行通信。如果此端口未开放，你的节点将不能组成集群。
Java客户端所在的Elasticsearch版本必须与集群中其他节点一致，否则，它们可能互相无法识别。
节点客户端（Node client）
节点客户端以无数据节点(none data node)身份加入集群，换言之，它自己不存储任何数据，但是它知道数据在集群中的具体位置，并且能够直接转发请求到对应的节点上。
Node客户端与transport client非常相似，它是官方Elasticsearch发行版的一部分，需要客户端运行Java等，但也有一些显着的差异。 如果群集对传输客户端是否已连接到群集中的某个节点非常不感兴趣，那么节点客户端将被视为群集的一部分。这意味着节点客户端的存在被存储在群集状态，并且群集中的所有其他节点将尝试建立到客户端的几个tcp连接。如果群集很大或使用多个客户端，这可能是一个显着的缺点。 这可能看起来有点荒谬，但是目前需要它，以便使服务器节点能够将对集群状态的更改传播到客户端。其最终结果是，节点客户端始终具有最新的集群状态和与Elasticsearch集群中每个其他节点的连接，这使得它能够在本地执行操作路由，是其自身请求的协调器等等。这会为每个请求跳过网络跳转，并导致集群中其余节点的工作量减少。