Hi,
It's quite unfortunate to see, that Bill who seemed very active in the
record-breaking 4000 entries for JAX-RS 2 is no longer willing to help.
It's certainly a loss for JAX-RS, MVC and other JSRs related to it.
As it was subject to Renewal Ballot and failed to produce an EDR (unlike
e.g. MVC) JSR 370 is on our "Black List" of inactive JSRs we already
discussed in this month's EC call. And expect to have further discussion
also likely with members of the community (at a JUG MeetUp I suggested and
Heather just arranged with the JUG) during the next EC F2F in Berlin.
We discussed how troubled JSRs like this one (maybe also from dual pressure
by having to lead the slightly better off MVC 1, too) could get help,
either from other EG members including possible co Spec Lead roles or in
severe cases the EG may ask us (the EC) to replace a non-responsive and
inactive Spec Lead. It's a pity if once active EG members like Bill feel
frustrated and drawn away, but given the overall situation his frustration
is not so hard to understand.
JAX-RS can be seen as an important JSR for the whole "Microservices" trend,
and even the companies that mainly "Cherrypick" from Java EE and rarely
contribute anything back use some standards like Servlets, JSP or JAX-RS
among others.
Maybe there are certain aspects that need no standardization and
implementations or other frameworks in this area are free to explore if
they want to add something to differentiate their product from others.
However, if there's no true innovation or need by the industry to be
addressed for JAX-RS then it's a valid question why even have JSR 370
rather than just a MR for the highly popular 339?;-)
Regards,
Werner Keil | JCP Executive Committee Member, JSR 363 Co Spec Lead |
Eclipse UOMo Lead, Babel Language Champion | Apache Committer
Twitter @wernerkeil | @UnitAPI | @JSR354 | @AgoravaProj | @DeviceMap
| #DevOps | #EclipseUOMo
Skype werner.keil | Google+ gplus.to/wernerkeil
On Thu, Apr 21, 2016 at 11:15 AM, <users-request_at_jax-rs-spec.java.net>
wrote:
> Table of contents:
>
> 1. [jax-rs-spec users] Re: client proxy framework - Marek Potociar <
> marek.potociar_at_oracle.com>
> 2. [jax-rs-spec users] Re: client proxy framework - Marek Potociar <
> marek.potociar_at_oracle.com>
> 3. [jax-rs-spec users] Re: client proxy framework - Willem Salembier <
> willem.salembier_at_gmail.com>
> 4. [jax-rs-spec users] Re: client proxy framework - Marek Potociar <
> marek.potociar_at_oracle.com>
> 5. [jax-rs-spec users] Re: client proxy framework - Willem Salembier <
> willem.salembier_at_gmail.com>
>
>
>
> ---------- Forwarded message ----------
> From: Marek Potociar <marek.potociar_at_oracle.com>
> To: users_at_jax-rs-spec.java.net
> Cc:
> Date: Wed, 20 Apr 2016 15:43:36 +0200
> Subject: [jax-rs-spec users] Re: client proxy framework
> While many people talk about how useful proxy clients are, I have yet to
> see a proposal that would make proxy clients not feel like RPC and would be
> also generic and useful enough to be considered for standardization.
>
> Sure most of the REST frameworks provide some proxy client support,
> including Jersey that serves at JAX-RS RI. That does not mean however that
> we should put it into the standard API, unless we are convinced that we
> have hit the nail on its head and this is the right way to go. Because
> whatever we put into the JAX-RS API stays there forever. And there are
> already parts of the API that I wish were never standardized.
> And sure, the companies behind the most popular REST (or REST-ish) APIs
> out there provide high-level dedicated clients. But those clients hand made
> and need to be maintained and versioned. And any code that uses those
> clients becomes very tightly coupled typically with a specific version of
> the API.
>
> So I choose to err on the side of not adding useful stuff, unless it is
> clear that we found the proper way how to do it.
>
> Feel free to take it as a challenge - come up with a *complete* and
> working proposal for a proxy API that honors HATEOAS principles, is format
> agnostic and does not introduce tight client-server coupling (or is able to
> deal with it somehow) and we will surely consider it for the spec.
> Since Jersey is JAX-RS RI, the code would have to be implemented on top of
> the master branch of Jersey and you would need to sign OCA agreement before
> we can even look at your code.
>
> Cheers,
> Marek
>
> On 19 Apr 2016, at 15:05, Jason Lee <jason_at_steeplesoft.com> wrote:
>
> If I may be so bold as to chime in, I'd have to side with Bill and Willem
> on the importance of this feature. Part of my work on GlassFish (and
> eventually Weblogic Server) was a framework to generate strongly-typed REST
> clients. If I recall things correctly, we had a very large, well-paying
> customer (who maybe shouldn't be named, but they make nice cars :) asking
> for it. Furthermore, if you look at all of the REST APIs available
> throughout the Tubes, you'll see language-specific wrappers in a *lot* of
> the cases (see, especially, the various Google APIs). There's clearly a
> desire for these on the part of API consumers, so it seems like a
> no-brainer for adding support for this to JAX-RS to give its users quick
> and easy client generation and maintenance. As a REST consumer myself, one
> of the first things I do is code a wrapper of some sort around, say, the
> Jersey client calls to provide a friendlier abstraction. So, for what it's
> worth, +1 on this feature.
>
> And while I'm addressing by betters already, allow me to say that I really
> hate HATEOAS. We were moving toward that with GF/WLS, but I hated every
> part of that. Bloated, somewhat complicated, and I never queried the server
> for what I could/should use. I knew the APIs, so I coded calls to the
> appropriate endpoints. In REST APIs I develop now since I've left Oracle, I
> don't even give it a second's thought. :)
>
>
> On 4/19/16 6:22 AM, willem.salembier_at_gmail.com wrote:
>
> I don't think it is fair to orient developers towards JAX-WS. JAX-WS is
> a dead API, and the industry has moved beyond SOAP. JAX-WS stopped
> evolving in 2001, and I don't think it stopped because it was
> feature-complete.
>
> A standardized proxy framework would be welcome because all JAX-RS
> runtimes already provide one.
> https://java.net/jira/browse/JAX_RS_SPEC-496
>
> You must admit that there are very little REST API's leveraging the
> HATEOAS principle and that JAX-RS offers very little to promote the use
> of HATEOAS. Poor man's tools like Link and URIBuilder are simply too
> limited to achieve the RESTafarian dream of fully decoupled
> applications.
>
> What I see in practice is lots of boilerplate JAX-RS client code with
> hardcoded assumptions about the API.
>
> Additionally, there are ways to define a proxy API that is more
> powerful and that makes abstraction of a strict URI scheme. e.g. by
> providing an alternative for the constant @Path annotations and taking
> a Link argument (coming from a previous interaction) instead.
>
>
> --
> Jason Leehttp://cubtracker.com http://blogs.steeplesoft.comhttp://twitter.com/jasondleehttp://blogs.steeplesoft.com/+http://blogs.steeplesoft.com/in
>
>
>
>
> ---------- Forwarded message ----------
> From: Marek Potociar <marek.potociar_at_oracle.com>
> To: jsr370-experts_at_jax-rs-spec.java.net
> Cc:
> Date: Wed, 20 Apr 2016 15:47:05 +0200
> Subject: [jax-rs-spec users] Re: client proxy framework
> Hi Bill,
>
> I wish you good luck in your future endeavours.
>
> Cheers,
> Marek
>
> On 18 Apr 2016, at 16:39, Bill Burke <bburke_at_redhat.com> wrote:
>
> Sigh..... I feel similarly about your SSE proposals, that they just don't
> belong in JAX-RS...But you are wrong about this proxy framework. Its only
> an RPC mechanism if users end up using it that way. Client app code is
> usually writing a method to encapsulate invoking on a specific REST
> service, this proxy framework just makes this process more efficient.
> Writing the same long boilerplate code for each and every client invocation
> gets quite tedious. Too bad you are too shortsighted to see it that way,
> but quite honestly, I just don't care that much anymore! :)
>
> So...cheers! Goodbye. That's it for me. Alessio Soldano will be taking
> over as Red Hat's rep on this Expert Group. I'll go about the proper
> chains to make that official. Personally, I hope to avoid the JCP for the
> remainder of my career. It was fun occasionally, but frustrating most
> other times.
>
> Finally, many of us are concerned on how much you guys have neglected the
> JAX-RS JSR lately. In talking to others at Red Hat and other companies,
> this seems to be a common occurrence for Oracle-led JSRs across the board.
> The responsible thing to do would be to hand off the torch if there is no
> desire or proper funds at Oracle to drive Java EE JSRs into the future.
> I've heard that some are considering action through the JCP if this neglect
> continues.
>
> On 4/18/2016 10:03 AM, Marek Potociar wrote:
>
> Crossposting what I just replied to Adam on users mailing list wrt. this
> thread:
> *I would suggest to direct all your users who want this feature to JAX-WS.
> That’s the proper RPC technology for this type of tight client-server
> coupling.*
>
> We have discussed this at length earlier in JAX-RS 2.0. The position of
> spec leads on this topic did not change since then.
>
> Marek
>
>
> On 06 Apr 2016, at 15:06, Bill Burke < <bburke_at_redhat.com>
> bburke_at_redhat.com> wrote:
>
> Ping. Again, this would be good feature to add IMO. Its simple to
> implement and would be used by a lot of developers. I need to know soon if
> this is something the spec leads are interested in. I'm about to renounce
> my JAX-RS EG membership and hand it off to somebody else at Red Hat as I'm
> really busy with other things. If there is interest in this proposal,
> I'll stick around to write it up.
>
> On 2/28/2016 6:13 PM, Bill Burke wrote:
>
> This is not a feature I came up with 1 week ago on a whim. Its a proven
> feature that has been around for 5+ years in Resteasy and is wildly
> popular. A number of other projects I'm involved with use it to publish
> their REST interface as its something users have demanded.
>
> I'd be happy to write it up, but I need to know soon as my schedule is
> really busy in 2016. IMO, it would probably be the most popular feature of
> 2.1 if it was added. Even non-Resteasy users would be familiar with it as
> its already documented in both revisions of my JAX-RS RESTFul Java O'Reilly
> books which have also been around for 5+ years. :)
>
> Again, it would be something like this:
>
> interface MyRestClient {
> @GET
> @Product("application/json")
> @Path("{name}")
> Customer get(@QueryParam("name") name);
> }
>
> Client client = ...;
> MyRestClient proxy = client.target(" <http://example.com/>
> http://example.com").proxy(MyRestClient.class);
>
> Customer cust = proxy.get("Bill Burke");
>
>
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com
>
>
>
> --
> Bill Burke
> JBoss, a division of Red Hathttp://bill.burkecentral.com
>
>
>
>
> ---------- Forwarded message ----------
> From: Willem Salembier <willem.salembier_at_gmail.com>
> To: users_at_jax-rs-spec.java.net
> Cc:
> Date: Wed, 20 Apr 2016 15:48:09 +0000
> Subject: [jax-rs-spec users] Re: client proxy framework
> Marek,
>
> One step before questioning existing proxy frameworks, I'd like to ask if
> you already have a shortlist of APIs in mind that are considered good
> examples of implementing HATEOAS principles? E.g. has the expert group
> already expressed which (emerging) standards (RFC 5988, HAL, JSON-LD,
> Hydra, Collection-JSON, etc) they consider good candidates for doing
> HATEOAS?
>
> My impression is the industry doesn't show real interest in achieving
> level 3 of REST maturity, which explains the huge popularity of API
> documenting frameworks like Swagger, RAML, Blueprint, etc. Even Roy
> Fielding who coined the term never bothered to elaborate his vision. So too
> many times HATEOAS stays a vague concept.
>
> So instead of waiting for a better proxy framework, aren't we really
> waiting for the next HATEOAS standard to emerge? And consequently, do we
> really need to wait to start defining a proxy framework before the industry
> decides on that HATEAOS standard? Or can we already deliver something
> practical for REST APIs level 2 in the field today?
>
> Best Regards,
> Willem
>
> On Wed, Apr 20, 2016 at 3:43 PM Marek Potociar <marek.potociar_at_oracle.com>
> wrote:
>
>> While many people talk about how useful proxy clients are, I have yet to
>> see a proposal that would make proxy clients not feel like RPC and would be
>> also generic and useful enough to be considered for standardization.
>>
>> Sure most of the REST frameworks provide some proxy client support,
>> including Jersey that serves at JAX-RS RI. That does not mean however that
>> we should put it into the standard API, unless we are convinced that we
>> have hit the nail on its head and this is the right way to go. Because
>> whatever we put into the JAX-RS API stays there forever. And there are
>> already parts of the API that I wish were never standardized.
>> And sure, the companies behind the most popular REST (or REST-ish) APIs
>> out there provide high-level dedicated clients. But those clients hand made
>> and need to be maintained and versioned. And any code that uses those
>> clients becomes very tightly coupled typically with a specific version of
>> the API.
>>
>> So I choose to err on the side of not adding useful stuff, unless it is
>> clear that we found the proper way how to do it.
>>
>> Feel free to take it as a challenge - come up with a *complete* and
>> working proposal for a proxy API that honors HATEOAS principles, is format
>> agnostic and does not introduce tight client-server coupling (or is able to
>> deal with it somehow) and we will surely consider it for the spec.
>> Since Jersey is JAX-RS RI, the code would have to be implemented on top
>> of the master branch of Jersey and you would need to sign OCA agreement
>> before we can even look at your code.
>>
>> Cheers,
>> Marek
>>
>> On 19 Apr 2016, at 15:05, Jason Lee <jason_at_steeplesoft.com> wrote:
>>
>> If I may be so bold as to chime in, I'd have to side with Bill and Willem
>> on the importance of this feature. Part of my work on GlassFish (and
>> eventually Weblogic Server) was a framework to generate strongly-typed REST
>> clients. If I recall things correctly, we had a very large, well-paying
>> customer (who maybe shouldn't be named, but they make nice cars :) asking
>> for it. Furthermore, if you look at all of the REST APIs available
>> throughout the Tubes, you'll see language-specific wrappers in a *lot* of
>> the cases (see, especially, the various Google APIs). There's clearly a
>> desire for these on the part of API consumers, so it seems like a
>> no-brainer for adding support for this to JAX-RS to give its users quick
>> and easy client generation and maintenance. As a REST consumer myself, one
>> of the first things I do is code a wrapper of some sort around, say, the
>> Jersey client calls to provide a friendlier abstraction. So, for what it's
>> worth, +1 on this feature.
>>
>> And while I'm addressing by betters already, allow me to say that I
>> really hate HATEOAS. We were moving toward that with GF/WLS, but I hated
>> every part of that. Bloated, somewhat complicated, and I never queried the
>> server for what I could/should use. I knew the APIs, so I coded calls to
>> the appropriate endpoints. In REST APIs I develop now since I've left
>> Oracle, I don't even give it a second's thought. :)
>>
>>
>> On 4/19/16 6:22 AM, willem.salembier_at_gmail.com wrote:
>>
>> I don't think it is fair to orient developers towards JAX-WS. JAX-WS is
>> a dead API, and the industry has moved beyond SOAP. JAX-WS stopped
>> evolving in 2001, and I don't think it stopped because it was
>> feature-complete.
>>
>> A standardized proxy framework would be welcome because all JAX-RS
>> runtimes already provide one.
>> https://java.net/jira/browse/JAX_RS_SPEC-496
>>
>> You must admit that there are very little REST API's leveraging the
>> HATEOAS principle and that JAX-RS offers very little to promote the use
>> of HATEOAS. Poor man's tools like Link and URIBuilder are simply too
>> limited to achieve the RESTafarian dream of fully decoupled
>> applications.
>>
>> What I see in practice is lots of boilerplate JAX-RS client code with
>> hardcoded assumptions about the API.
>>
>> Additionally, there are ways to define a proxy API that is more
>> powerful and that makes abstraction of a strict URI scheme. e.g. by
>> providing an alternative for the constant @Path annotations and taking
>> a Link argument (coming from a previous interaction) instead.
>>
>>
>> --
>> Jason Leehttp://cubtracker.com http://blogs.steeplesoft.comhttp://twitter.com/jasondleehttp://blogs.steeplesoft.com/+http://blogs.steeplesoft.com/in
>>
>>
>>
>
> ---------- Forwarded message ----------
> From: Marek Potociar <marek.potociar_at_oracle.com>
> To: users_at_jax-rs-spec.java.net
> Cc:
> Date: Wed, 20 Apr 2016 18:10:53 +0200
> Subject: [jax-rs-spec users] Re: client proxy framework
> We do not need to wait for a HATEOAS standard. What I am saying in this
> context is that whatever proxy framework API you come up with, it should
> not preclude me from designing my REST API in a way that is
> hypermedia-driven.
>
> Marek
>
> On 20 Apr 2016, at 17:48, Willem Salembier <willem.salembier_at_gmail.com>
> wrote:
>
> Marek,
>
> One step before questioning existing proxy frameworks, I'd like to ask if
> you already have a shortlist of APIs in mind that are considered good
> examples of implementing HATEOAS principles? E.g. has the expert group
> already expressed which (emerging) standards (RFC 5988, HAL, JSON-LD,
> Hydra, Collection-JSON, etc) they consider good candidates for doing
> HATEOAS?
>
> My impression is the industry doesn't show real interest in achieving
> level 3 of REST maturity, which explains the huge popularity of API
> documenting frameworks like Swagger, RAML, Blueprint, etc. Even Roy
> Fielding who coined the term never bothered to elaborate his vision. So too
> many times HATEOAS stays a vague concept.
>
> So instead of waiting for a better proxy framework, aren't we really
> waiting for the next HATEOAS standard to emerge? And consequently, do we
> really need to wait to start defining a proxy framework before the industry
> decides on that HATEAOS standard? Or can we already deliver something
> practical for REST APIs level 2 in the field today?
>
> Best Regards,
> Willem
>
> On Wed, Apr 20, 2016 at 3:43 PM Marek Potociar <marek.potociar_at_oracle.com>
> wrote:
>
>> While many people talk about how useful proxy clients are, I have yet to
>> see a proposal that would make proxy clients not feel like RPC and would be
>> also generic and useful enough to be considered for standardization.
>>
>> Sure most of the REST frameworks provide some proxy client support,
>> including Jersey that serves at JAX-RS RI. That does not mean however that
>> we should put it into the standard API, unless we are convinced that we
>> have hit the nail on its head and this is the right way to go. Because
>> whatever we put into the JAX-RS API stays there forever. And there are
>> already parts of the API that I wish were never standardized.
>> And sure, the companies behind the most popular REST (or REST-ish) APIs
>> out there provide high-level dedicated clients. But those clients hand made
>> and need to be maintained and versioned. And any code that uses those
>> clients becomes very tightly coupled typically with a specific version of
>> the API.
>>
>> So I choose to err on the side of not adding useful stuff, unless it is
>> clear that we found the proper way how to do it.
>>
>> Feel free to take it as a challenge - come up with a *complete* and
>> working proposal for a proxy API that honors HATEOAS principles, is format
>> agnostic and does not introduce tight client-server coupling (or is able to
>> deal with it somehow) and we will surely consider it for the spec.
>> Since Jersey is JAX-RS RI, the code would have to be implemented on top
>> of the master branch of Jersey and you would need to sign OCA agreement
>> before we can even look at your code.
>>
>> Cheers,
>> Marek
>>
>> On 19 Apr 2016, at 15:05, Jason Lee <jason_at_steeplesoft.com> wrote:
>>
>> If I may be so bold as to chime in, I'd have to side with Bill and Willem
>> on the importance of this feature. Part of my work on GlassFish (and
>> eventually Weblogic Server) was a framework to generate strongly-typed REST
>> clients. If I recall things correctly, we had a very large, well-paying
>> customer (who maybe shouldn't be named, but they make nice cars :) asking
>> for it. Furthermore, if you look at all of the REST APIs available
>> throughout the Tubes, you'll see language-specific wrappers in a *lot* of
>> the cases (see, especially, the various Google APIs). There's clearly a
>> desire for these on the part of API consumers, so it seems like a
>> no-brainer for adding support for this to JAX-RS to give its users quick
>> and easy client generation and maintenance. As a REST consumer myself, one
>> of the first things I do is code a wrapper of some sort around, say, the
>> Jersey client calls to provide a friendlier abstraction. So, for what it's
>> worth, +1 on this feature.
>>
>> And while I'm addressing by betters already, allow me to say that I
>> really hate HATEOAS. We were moving toward that with GF/WLS, but I hated
>> every part of that. Bloated, somewhat complicated, and I never queried the
>> server for what I could/should use. I knew the APIs, so I coded calls to
>> the appropriate endpoints. In REST APIs I develop now since I've left
>> Oracle, I don't even give it a second's thought. :)
>>
>>
>> On 4/19/16 6:22 AM, willem.salembier_at_gmail.com wrote:
>>
>> I don't think it is fair to orient developers towards JAX-WS. JAX-WS is
>> a dead API, and the industry has moved beyond SOAP. JAX-WS stopped
>> evolving in 2001, and I don't think it stopped because it was
>> feature-complete.
>>
>> A standardized proxy framework would be welcome because all JAX-RS
>> runtimes already provide one.
>> https://java.net/jira/browse/JAX_RS_SPEC-496
>>
>> You must admit that there are very little REST API's leveraging the
>> HATEOAS principle and that JAX-RS offers very little to promote the use
>> of HATEOAS. Poor man's tools like Link and URIBuilder are simply too
>> limited to achieve the RESTafarian dream of fully decoupled
>> applications.
>>
>> What I see in practice is lots of boilerplate JAX-RS client code with
>> hardcoded assumptions about the API.
>>
>> Additionally, there are ways to define a proxy API that is more
>> powerful and that makes abstraction of a strict URI scheme. e.g. by
>> providing an alternative for the constant @Path annotations and taking
>> a Link argument (coming from a previous interaction) instead.
>>
>>
>> --
>> Jason Leehttp://cubtracker.com http://blogs.steeplesoft.comhttp://twitter.com/jasondleehttp://blogs.steeplesoft.com/+http://blogs.steeplesoft.com/in
>>
>>
>>
>
>
> ---------- Forwarded message ----------
> From: Willem Salembier <willem.salembier_at_gmail.com>
> To: users_at_jax-rs-spec.java.net
> Cc:
> Date: Wed, 20 Apr 2016 19:32:10 +0000
> Subject: [jax-rs-spec users] Re: client proxy framework
> I think you're circumventing my question. What are your goals in terms of
> supporting hypermedia-driven APIs? It matters, because it can vary from (a)
> simple navigation through RFC 5988 links up to (z) full-blown
> meta-descriptions that describe how loosely coupled clients should render
> an UI and build the next message in the ongoing client-server conversation.
>
> Again, what are your references and examples?
>
>
>
> On Wed, Apr 20, 2016 at 6:11 PM Marek Potociar <marek.potociar_at_oracle.com>
> wrote:
>
>> We do not need to wait for a HATEOAS standard. What I am saying in this
>> context is that whatever proxy framework API you come up with, it should
>> not preclude me from designing my REST API in a way that is
>> hypermedia-driven.
>>
>> Marek
>>
>> On 20 Apr 2016, at 17:48, Willem Salembier <willem.salembier_at_gmail.com>
>> wrote:
>>
>> Marek,
>>
>> One step before questioning existing proxy frameworks, I'd like to ask if
>> you already have a shortlist of APIs in mind that are considered good
>> examples of implementing HATEOAS principles? E.g. has the expert group
>> already expressed which (emerging) standards (RFC 5988, HAL, JSON-LD,
>> Hydra, Collection-JSON, etc) they consider good candidates for doing
>> HATEOAS?
>>
>> My impression is the industry doesn't show real interest in achieving
>> level 3 of REST maturity, which explains the huge popularity of API
>> documenting frameworks like Swagger, RAML, Blueprint, etc. Even Roy
>> Fielding who coined the term never bothered to elaborate his vision. So too
>> many times HATEOAS stays a vague concept.
>>
>> So instead of waiting for a better proxy framework, aren't we really
>> waiting for the next HATEOAS standard to emerge? And consequently, do we
>> really need to wait to start defining a proxy framework before the industry
>> decides on that HATEAOS standard? Or can we already deliver something
>> practical for REST APIs level 2 in the field today?
>>
>> Best Regards,
>> Willem
>>
>> On Wed, Apr 20, 2016 at 3:43 PM Marek Potociar <marek.potociar_at_oracle.com>
>> wrote:
>>
>>> While many people talk about how useful proxy clients are, I have yet to
>>> see a proposal that would make proxy clients not feel like RPC and would be
>>> also generic and useful enough to be considered for standardization.
>>>
>>> Sure most of the REST frameworks provide some proxy client support,
>>> including Jersey that serves at JAX-RS RI. That does not mean however that
>>> we should put it into the standard API, unless we are convinced that we
>>> have hit the nail on its head and this is the right way to go. Because
>>> whatever we put into the JAX-RS API stays there forever. And there are
>>> already parts of the API that I wish were never standardized.
>>> And sure, the companies behind the most popular REST (or REST-ish) APIs
>>> out there provide high-level dedicated clients. But those clients hand made
>>> and need to be maintained and versioned. And any code that uses those
>>> clients becomes very tightly coupled typically with a specific version of
>>> the API.
>>>
>>> So I choose to err on the side of not adding useful stuff, unless it is
>>> clear that we found the proper way how to do it.
>>>
>>> Feel free to take it as a challenge - come up with a *complete* and
>>> working proposal for a proxy API that honors HATEOAS principles, is format
>>> agnostic and does not introduce tight client-server coupling (or is able to
>>> deal with it somehow) and we will surely consider it for the spec.
>>> Since Jersey is JAX-RS RI, the code would have to be implemented on top
>>> of the master branch of Jersey and you would need to sign OCA agreement
>>> before we can even look at your code.
>>>
>>> Cheers,
>>> Marek
>>>
>>> On 19 Apr 2016, at 15:05, Jason Lee <jason_at_steeplesoft.com> wrote:
>>>
>>> If I may be so bold as to chime in, I'd have to side with Bill and
>>> Willem on the importance of this feature. Part of my work on GlassFish (and
>>> eventually Weblogic Server) was a framework to generate strongly-typed REST
>>> clients. If I recall things correctly, we had a very large, well-paying
>>> customer (who maybe shouldn't be named, but they make nice cars :) asking
>>> for it. Furthermore, if you look at all of the REST APIs available
>>> throughout the Tubes, you'll see language-specific wrappers in a *lot* of
>>> the cases (see, especially, the various Google APIs). There's clearly a
>>> desire for these on the part of API consumers, so it seems like a
>>> no-brainer for adding support for this to JAX-RS to give its users quick
>>> and easy client generation and maintenance. As a REST consumer myself, one
>>> of the first things I do is code a wrapper of some sort around, say, the
>>> Jersey client calls to provide a friendlier abstraction. So, for what it's
>>> worth, +1 on this feature.
>>>
>>> And while I'm addressing by betters already, allow me to say that I
>>> really hate HATEOAS. We were moving toward that with GF/WLS, but I hated
>>> every part of that. Bloated, somewhat complicated, and I never queried the
>>> server for what I could/should use. I knew the APIs, so I coded calls to
>>> the appropriate endpoints. In REST APIs I develop now since I've left
>>> Oracle, I don't even give it a second's thought. :)
>>>
>>>
>>> On 4/19/16 6:22 AM, willem.salembier_at_gmail.com wrote:
>>>
>>> I don't think it is fair to orient developers towards JAX-WS. JAX-WS is
>>> a dead API, and the industry has moved beyond SOAP. JAX-WS stopped
>>> evolving in 2001, and I don't think it stopped because it was
>>> feature-complete.
>>>
>>> A standardized proxy framework would be welcome because all JAX-RS
>>> runtimes already provide one.
>>> https://java.net/jira/browse/JAX_RS_SPEC-496
>>>
>>> You must admit that there are very little REST API's leveraging the
>>> HATEOAS principle and that JAX-RS offers very little to promote the use
>>> of HATEOAS. Poor man's tools like Link and URIBuilder are simply too
>>> limited to achieve the RESTafarian dream of fully decoupled
>>> applications.
>>>
>>> What I see in practice is lots of boilerplate JAX-RS client code with
>>> hardcoded assumptions about the API.
>>>
>>> Additionally, there are ways to define a proxy API that is more
>>> powerful and that makes abstraction of a strict URI scheme. e.g. by
>>> providing an alternative for the constant @Path annotations and taking
>>> a Link argument (coming from a previous interaction) instead.
>>>
>>>
>>> --
>>> Jason Leehttp://cubtracker.com http://blogs.steeplesoft.comhttp://twitter.com/jasondleehttp://blogs.steeplesoft.com/+http://blogs.steeplesoft.com/in
>>>
>>>
>>>
>>
> End of digest for list users_at_jax-rs-spec.java.net - Thu, 21 Apr 2016
>
>