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 Lee
http://cubtracker.com
http://blogs.steeplesoft.com
http://twitter.com/jasondlee
http://blogs.steeplesoft.com/+
http://blogs.steeplesoft.com/in