users@jax-rs-spec.java.net

[jax-rs-spec users] Re: REST server/client contract

From: Willem Salembier <willem.salembier_at_gmail.com>
Date: Thu, 22 Sep 2016 06:02:49 +0000

Hi Jernej,

You can vote for and discuss the proxy framework pro & cons on
https://java.net/jira/browse/JAX_RS_SPEC-496

I understand the concept of self-describing REST APIs well, but the current
tools in JAX-RS (Link and the boilerplate/error-prone LinkBuilder classes)
will not get us there. Plus, most industry APIs haven't reached the
maturity level of HATEOAS and will not until we have the right
standards/tools. Nowadays I see the other camps (Swagger, RAML, etc)
winning, and it shouldn't be like that.

Willem
On Wed, 21 Sep 2016 at 01:24, Marek Potociar <marek.potociar_at_oracle.com>
wrote:

> The problem with this type of client/server contract is that it promotes
> tight coupling, which goes against the grain of the whole REST philosophy.
> You still can rely on JAXB (and soon hopefully on JSONB as well) specs to
> get at least the model-level contract covered, if you decide to do so…
>
> Marek
>
>
> > On 23 Aug 2016, at 00:19, jernej.pajntar_at_gmail.com wrote:
> >
> > Am I really the only one who thinks that contracts between
> > server/client in an enterprise application are important?
> >
> > The RESTeasy framework did a great job providing the contract interface
> > with Resteasy PROXY Framework*.
> >
> > But with the rise of ASYNC processing it became useless, because the
> > return type cannot be inspected as far as i know.
> >
> > @GET
> > public void asyncGet(@Suspended final AsyncResponse asyncResponse)
> >
> > Does anyone have any solutions for this problem?
> >
> > *
> > https://docs.jboss.org/resteasy/docs/3.0-beta-3/userguide/html/RESTEasy
> > _Client_Framework.html
>
>