对于JVM应用程序，是否有充分的理由使用Elasticsearch REST API？

Question

我正在开发一个Java应用程序，其中包括Elasticsearch。

到目前为止，我已经使用了Java节点客户端。然后前段时间我从一些同事那里听说REST API是首选，原因如下：

1. 能够在不影响传输客户端版本的情况下升级Elasticsearch，即Java客户端版本取决于运行ES群集的版本
2. 将在即将发布的版本中弃用节点/传输客户端吗？
3. 安全

我现在正试图弄清楚这有多少。

说到＃1，the Elasticsearch docs state它（通常）足以使客户端和ES集群具有相同的主要版本。因此，REST API在这里并没有真正提供更好的东西。

然后，＃3由Shield处理。

我找不到关于＃2的任何信息。

从上面的信息中，我可能想在我的Java应用程序中使用REST API的唯一原因是版本独立性，只是为了安全起见。除此之外，并不多;那是真的吗？并且不推荐使用节点/传输客户端吗？

Answer 1

我不是ES专家，但我们只是问自己同样的问题，这是我们对这个主题的看法。

1. ES客户端版本与ES服务器版本：
   • 原生客户端遵循您声明的规则：主要版本兼容性。直到最近才出现这种情况，并且对于真正具体的功能（例如Percolator），这仍然不是（对次要版本进行更改），
   • 似乎现在最好的HTTP客户端抽象Jest具有相同的约束：documentation表示版本1.x不适用于2.x，
   • 最后的解决方案是使用低级别的HTTP客户端，但丢失了流畅的Java抽象。这不符合比较，
   • 您不能使用基于本机客户端的Java应用程序来解决ES的混合版本（在具有1.x和2.x实例的异构环境中）。应该可以使用HTTP客户端，因此可以简化一些渐进式迁移方案。
2. 原生客户弃用：
   • 没有明确说明，但there will be an official HTTP client for version 5.x。有了这个，有两个客户有什么意义呢？
3. 安全：
   • 如果需要（例如Apache前端）或使用https://github.com/Asquera/elasticsearch-http-basic，
   ，基本的HTTP安全性很容易设置一些中间件
   • Shield是官方的，适用于本机和HTTP，但不是免费的......

在我们的应用中，我们使用的是Spring Data ES。非常容易使用，代码很少，但是版本滞后（在ES 2发布后支持2.x 6个月）并且基于本机客户端。从我们的观点来看，这些权衡取决于发展效率。

最后，SAAS仅提供HTTP API，因此在这种情况下，您无法选择。