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