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