provide Proxy Interface at the client side

[nimo23]

With RestEasy, we can define an interface to make restful calls at the client side:

@Path("https://www.service/query")
@Produces({ MediaType.APPLICATION_JSON, MediaType.TEXT_PLAIN })
public interface UserClient {

    @GET
    String getUser(@QueryParam("id") Integer id);

}

ResteasyWebTarget target = (ResteasyWebTarget) httpClient.target("");
var userClient = target.proxy(UserClient.class);
// make GET-request and returns string of response body
String string = userClient.getUser(1); 

Would be nice to provide this by jaxrs-api.

[jansupol]

This is basically part of the functionality of Microprofile REST Client. I assume the discussion about the relation between JAX-RS and the MP rest client will come

[nimo23]

In my opinion, JAX-RS should be merged with Microprofile REST Client and should be called Open-EE-RS with namespace "openee.rs.* or "ee4j.rs". The "Microprofile REST Client" and "JAX-RS" should be continued as Open-EE-RS. (The same goes for "Open-EE-Persistence", "Open-EE-Security", "Open-EE-Config", etc.)

[ggam]

So you propose to abandon the Jakarta EE name?

El vie., 7 jun. 2019 9:23, nimo23 notifications@github.com escribió:

In my opinion, JAX-RS should be merged with Microprofile REST Client and should be called "Open-EE-Restful" with namespace "openee.restful.* or "ee4j.restful". The same goes for "Open-EE-Persistence", "Open-EE-Security", "Open-EE-Config", etc.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/eclipse-ee4j/jaxrs-api/issues/769?email_source=notifications&email_token=AAQC44BCYKJ3RGI5GX4WMZLPZIEFPA5CNFSM4HVFW6NKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODXFB3MQ#issuecomment-499785138, or mute the thread https://github.com/notifications/unsubscribe-auth/AAQC44DGW52DFTAO3XAPX3DPZIEFPANCNFSM4HVFW6NA .

[nimo23]

So you propose to abandon the Jakarta EE name?

Imagine the follwing:

• Open-EE-RS (former: Microprofile REST Client + JAX-RS) with namespace openee.rs.*
• Open-EE-Persistence (former JPA) with namespace openee.persistence.*
• Open-EE-Security (former JEE-Security) with namespace openee.security.*
• Open-EE-Metrics (former Microprofile Health) with namespace openee.metrics.*
• etc.

I think, it is better to merge the efforts into Open-EE-X than continue with Jakarte EE and Microprofile side by side. In essence, Jakarta EE and Microprofile have the same goal: to provide enterprise features not available in Java SE. I think, both names will not be strong enough for the feature to make the intention clear and to attract. Forget the microservices and all the other buzzword which leads to microprofile..what is micro..why the island..what is "open enterprise edition" - you know, the last is clear: I open the enterprise edition for restful services with open.ee.restful.* (Open-EE-Restful). By the way, ee4j propagates that this is an Enterprise edtion for Java, while open.ee. propagates that this is a Specification for Enterprise Edtion not necessarily for or written in Java..

[chkal]

I don't think that this issue is the best place to discuss your Open-EE idea. And I'm pretty sure that there won't be another name change.

[Cousjava]

@nimo23 See https://github.com/eclipse-ee4j/ee4j/issues/1 for the debate on naming. Open EE was considered and ultimately rejected in favour of Jakarta EE.

[nimo23]

@Cousjava thanks for sharing the link. I did not know about it.

The discussion about the relation between JAX-RS and the MP rest client (and in general, the microprofile and jakarte ee) must come because it's a pitty to spend resources on projects with so much overlapping instead of merging the efforts into one. However, as @chkal already said, this issue is not the best place to discuss this.

[derekm]

This is also something I've been using since 2012 as Jersey's WebResourceFactory:

https://github.com/eclipse-ee4j/jersey/blob/master/ext/proxy-client/src/main/java/org/glassfish/jersey/client/proxy/WebResourceFactory.java

When MicroProfile REST Client spec was being written, I made sure the spec writers considered @BeanParams and sub-resource locators, etc.

I have many facilities built around WebResourceFactory.

[derekm]

Some interesting PRs involving WebResourceFactory proxy client from before the Eclipse donation:

JERSEY-1653: Add support for @BeanParam in jersey-proxy-client https://github.com/jersey/jersey/pull/235

JERSEY-3248: support parameter converters in WebResourceFactory https://github.com/jersey/jersey/pull/269