JVMアプリケーションの場合、Elasticsearch REST APIを使用する正当な理由はありますか？

Question

私は、特にElasticsearchを使ってJavaアプリケーションを開発しています。

ここまでは、Javaノードクライアントを使用しました。その後、いくつかの時間前、私はREST APIは次のような理由から、好ましいことが、いくつかの同僚から聞いた：Javaクライアントのバージョンが何であるかのバージョンに依存している。すなわち、

1. は、トランスポート・クライアントのバージョンをぶつけずにElasticsearchをアップグレードすることができることESクラスタの実行
2. 今後のリリースでは、ノード/トランスポートクライアントは廃止予定ですか？
3. セキュリティ

私は今、これが保持しているどのくらいのを見つけるためにしようとしています。

＃1の場合、the Elasticsearch docs stateは、クライアントとESクラスタが同じメジャーバージョンであるほど（通常は）十分です。だから、REST APIは本当にここで何か良いものを提供していません。

次に、＃3はShieldによって処理されています。

＃2については何も見つかりませんでした。

上記の情報から、JavaアプリケーションでREST APIを使用する唯一の理由は、バージョンの独立性です。これは安全な側にあるためです。それ以外は、それほどではありません。それは実際には本当ですか？そして、ノード/トランスポートクライアントは廃止されることは本当ですか？

Answer 1

私はESの専門家ではありませんが、私たちは同じ質問をしているだけであり、ここでは私たちの考えがあります。 ESサーバーのバージョン対

1. ESクライアントバージョン：
   • ネイティブクライアントはあなたが述べた規則に従います。メジャーバージョンとの互換性を。
   • これまでのところ最高のHTTPクライアント抽象化であるJestは、同じ制約を持っているようです：documentation（これは現在のところ、Percolatorのような特殊な機能ではありません）バージョン1.xは2.xでは動作しません。
   • 最後の解決策は、低レベルのHTTPクライアントを使用することですが、流暢なJava抽象概念を失うことになります。
   • ESの混合バージョンにネイティブクライアントに基づくJavaアプリケーション（1.xインスタンスと2.xインスタンスの両方が混在する環境の場合）を指定することはできません。 HTTPクライアントで可能でなければならないため、たとえば、いくつかの段階的な移行シナリオを緩和することができます。
2. ネイティブクライアント非推奨：それは明確に述べられていない
   • が、there will be an official HTTP client for version 5.x。それで、2人のクライアントを持つことのポイントは何ですか？
3. セキュリティ：
   • 基本的なHTTPのセキュリティが必要な場合（たとえば、Apacheのフロントエンド）いくつかのミドルウェアとのセットアップが簡単であるかhttps://github.com/Asquera/elasticsearch-http-basicを使用して、
   • シールドは、公式でネイティブとHTTPの両方で動作しますが、ではありません我々のアプリで無料...

、我々は春データESを使用しています。非常に少数のコード行で非常に使いやすいですが、バージョンの遅れ（ES 2のリリース後6ヶ月間のサポートが2）に悩まされ、ネイティブクライアントに基づいています。私たちの視点からは、開発効率の点でトレードオフの価値があります。

最後に、SAASではHTTP APIしか提供していないため、この場合は選択肢がありません。