I think it's better to use official client. REST API will also call Java
API internally. so if you use REST it will be Java -> REST -> Java.
What do you mean by multiplatform? Android? I'm not quite sure ES Java API
works on Android or not, but I think the Android shouldn't talk to ES
directly.
Regards,
Kevin
On Wednesday, March 26, 2014 9:42:19 PM UTC+11, Subhadip Bagui wrote:
My app is in Java only. So what I mean is should I use elasticsearch Java
client or available REST api's only using HttpClient and all.
What will be more flexiable for multiplatform ingration ?
The Java API is said to have better performance (and I believe that). The
drawbacks are that you must use the exact same version of the java API
library on the client as the server runs, as well as the same version of
Java. So upgrades suck.
Not true anymore: the java client has been compatible between minor
versions since 0.90 as far as I remember. 1.0.0 client is currently working
just fine against my 1.0.1 cluster, and my experimentation today shows that
it also works fine against 1.1.0. So this used to be a nightmare requiring
synchronised upgrades, but hasn't been for a while.
FWIW we use the java client (in transport client mode) extensively from our
scala apps, and it works brilliantly. I'd definitely recommend.
On Wednesday, 26 March 2014 11:45:19 UTC, Martin Forssen wrote:
The Java API is said to have better performance (and I believe that). The
drawbacks are that you must use the exact same version of the java API
library on the client as the server runs, as well as the same version of
Java. So upgrades suck.
Using same version on all nodes of a cluster still holds. Otherwise you
will get unpredictable behavior, especially in case of using new features.
Jörg
On Wed, Mar 26, 2014 at 1:12 PM, Graham Tackley graham@tackley.net wrote:
Not true anymore: the java client has been compatible between minor
versions since 0.90 as far as I remember. 1.0.0 client is currently working
just fine against my 1.0.1 cluster, and my experimentation today shows that
it also works fine against 1.1.0. So this used to be a nightmare requiring
synchronised upgrades, but hasn't been for a while.
FWIW we use the java client (in transport client mode) extensively from
our scala apps, and it works brilliantly. I'd definitely recommend.
On Wednesday, 26 March 2014 11:45:19 UTC, Martin Forssen wrote:
The Java API is said to have better performance (and I believe that). The
drawbacks are that you must use the exact same version of the java API
library on the client as the server runs, as well as the same version of
Java. So upgrades suck.
I believe this is true again. Aggregations API recently changed, and code
no longer compiles. The REST apis definitely change at a slower rate.
On Wednesday, March 26, 2014 8:12:56 AM UTC-4, Graham Tackley wrote:
Not true anymore: the java client has been compatible between minor
versions since 0.90 as far as I remember. 1.0.0 client is currently working
just fine against my 1.0.1 cluster, and my experimentation today shows that
it also works fine against 1.1.0. So this used to be a nightmare requiring
synchronised upgrades, but hasn't been for a while.
FWIW we use the java client (in transport client mode) extensively from
our scala apps, and it works brilliantly. I'd definitely recommend.
On Wednesday, 26 March 2014 11:45:19 UTC, Martin Forssen wrote:
The Java API is said to have better performance (and I believe that). The
drawbacks are that you must use the exact same version of the java API
library on the client as the server runs, as well as the same version of
Java. So upgrades suck.
I use a in house developed java rest client for elasticsearch.
Unfortunately it's not in any shape to untangle from our code base and put
on Github yet but I might consider that if there's more interest.
Basically I use apache httpclient, I implemented a simple round robin
strategy so I can failover if nodes go down, and I implemented a simple
rest client around this to support put/post/delete/get requests. Also added
some basic interpretation of statuses and have mapped those to sensible
exceptions.
The idea is that this client is wrapped with another client that supports
more high level APIs that are exposed from elasticsearch. So you can do
things like index/delete documents, manage aliases, do bulk indexing etc.
My long term goal was actually to have two implementations of that client
one for REST and one for embedded elasticsearch. That would be an
interesting project because it would give you choice. Except, I never got
around to doing the embedded client implementation since we don't really
need it so far. Something else that we use is to model the query DSL using
static java methods and provides a simple DSL for creating queries in Java.
This in turn uses my github jsonj project that allows you to
programmatically manipulate json structures.
None of this is particularly complicated but altogether there is quite a
bit of code to write and quite a few things you can get wrong. It's always
hard to separate the general purpose stuff from the application specific
stuff and thats one reason why I have not yet put this code out.
Jilles
On Wednesday, March 26, 2014 10:46:16 AM UTC+1, Subhadip Bagui wrote:
Hi,
We have a cloud management framework where all the event data are to be
stored in elasticsearch. I have to start the client side code for this.
I need a suggestion here. Which one should I use, elasticsearch Java API
or REST API for the client ?
Kindly suggest and mention the pros and cons for the same so it will be
easy for me to decide the product design than latter hassel.
Apache, Apache Lucene, Apache Hadoop, Hadoop, HDFS and the yellow elephant
logo are trademarks of the
Apache Software Foundation
in the United States and/or other countries.