The JAX-RS interface can just be a client-side interface. You don't have to implement it on the server, if you don't need to. In this case the client-side interface would just describe the HTTP interaction with the existing endpoints.
Also, javax.ws.rs.core.Response can be used in an JAX-RS interface that is used by Errai on the client. You can use the ResponseCallback to get a GWT Response object for it, see https://docs.jboss.org/author/display/ERRAI/Errai+JAX-RS#ErraiJAX-RS-HandlingResponses.
The advantage of still using a JAX-RS interface and therefore using Errai JAX-RS is that your interactions with the server are declarative and in one place. Plus you can use Errai's marshalling system (for your shared transfer objects).
On the server, you can either deploy the errai-jaxrs-provider, so your endpoint generates Errai's json or configure it to use Jackson.
We could add an additional client API that does not rely on JAX-RS annotations but I am not sure what the benefits would be. For instance, we could add suppport for the new client API of JAX-RS 2.0. What do you think?
Thanks for your fast support.
So in case I use the interface just in the client, I have to write java classes exactly matching the JSON format right? I think this can be challenging (still I like this solution the most at that moment).
I read about the client response object, but I didn’t figure out if I’m able to use any demarshalling framework. Can I use an util that converts the text from the response to objects?
that's perfect. Thanks a lot. As the first service I want to call uses Jersey I will give Errai a shot.
Beside of that I found this tutorial covering JSON in GWT: https://developers.google.com/web-toolkit/doc/latest/tutorial/JSON. If the Marshalling doesn't work I try creating overlays and use Errai UI.