A frequently asked question after my JAX-RS presentations had been whether there is some automatic means of client generation, so programmers don't need to deal with the http stuff (methods, content types, etc.). Some of them asked for WADL based code generators for example. My default answer is that it makes not much sense due to two reasons. First, the design of JAX-RS is http-driven. So why hiding http below a curtain of a different language? Second, how to obtain WADL (or here: the interface) when the server is developed in Python or JavaScript?
So yes, it is definitively _frequently asked_. But is it _really_ useful, too?
-Markus
-----Original Message-----
From: Sergey Beryozkin [mailto:sberyozkin_at_talend.com]
Sent: Montag, 19. Oktober 2015 22:00
To: jsr370-experts_at_jax-rs-spec.java.net
Subject: Re: Client proxy framework
The minor problem with proxies is that if you have multiple Consumes there's no way to indicate that you want a particular Content-Type.
Only using an implementation specific mechanism.
Note each sub-resource locator on the interface is also a proxy.
It is also not possible to control client-side async calls with proxies - but otherwise I agree with Bill - very popular feature.
Sergey
On 19/10/15 20:55, Markus KARG wrote:
> This is an interesting feature, which shortens development time for clients, and prevents hard-to-find typos. But I have two questions:
>
> (1) If I write a resource class that implements that interface, will it inherit the annotations?
>
> (2) How does the framework handle MIME types?
>
> -Markus
>
> -----Original Message-----
> From: Bill Burke [mailto:bburke_at_redhat.com]
> Sent: Montag, 19. Oktober 2015 20:16
> To: jsr370-experts_at_jax-rs-spec.java.net
> Subject: Client proxy framework
>
> Resteasy's client proxy frameork has been a very popular feature and in use for 6+ years. Basically it allows you to use JAX-RS annotations on the client side to create a typed client proxy. i.e.
>
> @Path("/")
> public interface MyService {
>
> @GET
> MyData getData(@QueryParam("param") String param);
>
> @POST
> Response postData(@FormParam("param") int param);
>
> }
>
> Then, you can take this interface and generate a client proxy:
>
> Client client = ClientBuilder.newClient(); MyService service =
> client.proxy(MyService.class);
>
> MyData data = service.getData("value");
>
> There's other minor details involved, but do you get the gist? Again, this is a very popular feature and IMO, a very natural extension to the client api.
>
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com
>