> > I didn't want to say that JAX-RS must prevent people from doing non-
> > REST,
> > but I wanted to say that JAX-RS should not motivate to do so (or
> > even do
> > non-REST things by itself).
> Agreed.
> I also like to say that the developer needs to understand the REST
> constraints and understand the pros and cons they introduce. And, that
> it is OK not to apply all the constraints of REST as long as one
> understands what consequences that has on the application
> architecture. It is not something i would encourage but i can
> understand why that needs to happen when solving certain practical
> engineering problems.
Agreed. It makes sense to use only that building bricks that make sense in a
particular case. From the pure definition, I personally would then not name
it "REST" to keep things clear, but I understand that for many people it is
attractive to call it "REST" even without HATEOAS.
> > Okay, so at least *I* misunderstood the proposal: I thought the
> > target was
> > to do HATEOAS (exactly that, in the REST sense), not to just "anyhow"
> > support hypertext.
> I often interchange hypertext or hypermedia with HATEOAS because it is
> easier to say and write. Apologies if i confused matters.
No problem, it seems we cleared the misunderstanding meanwhile.
> An API cannot "do HATEOAS" anymore than it can "do REST". Only an
> application can apply the REST constraints to its architecture to
> induce the desirable properties.. An API can make it easier to apply
> those constraints. We want to make it easier for developers to "do
> HATEOAS" with their applications.
No doubt about that, just had the impression that the API is likely to allow
two things that would foil this idea: (a) Allowing the user to use any other
header than "Link" (possibly proprietary "fancy" ones), (b) Allowing the
user to defined links which will not transfer any state at all but just
invoke any server sided method, which would result easily in RPC-style
applications with the "JAX-RS" label on it, which we should prevent.