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 集群中每个其他节点的连接，这使得它能够在本地执行操作路由，是其自身请求的协调器等等。这会为每个请求跳过网络跳转，并导致集群中其余节点的工作量减少。