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
>
>
>