I see the value in this if you are expecting clients to construct the URLs
for your resources.
We've opted to avoid this challenge by telling clients that the URL pattern
is NOT warrantied. All invocations are expected to be made by following a
link received on a prior invocation. This allows for a very simple client
that only needs to know how to find and follow links by rel.
I know we already spent some time on this and have shot HATEOAS down, but
just want to highlight that for those that do focus on representations and
links over resources that this type of feature doesn't provide much value.
However sounds like the majority of folks are doing resource oriented REST
so this would be great for them.
-Casey
On Wed, Oct 21, 2015 at 11:15 AM Markus KARG <markus_at_headcrashing.eu> wrote:
> Bill,
>
> unfortunately I abstain from a vote. I like the proposal, it solves a
> problem often asked by my clients, but I have not met people that really
> _need_ it (it's just their personal lazyness). So I hope you're not
> disappointed that I will abstain here and let you vendors decide.
>
> -Markus
>
> -----Original Message-----
> From: Bill Burke [mailto:bburke_at_redhat.com]
> Sent: Mittwoch, 21. Oktober 2015 15:09
> To: jsr370-experts_at_jax-rs-spec.java.net
> Subject: Re: Client proxy framework
>
> On 10/20/2015 5:07 PM, Markus KARG wrote:
> > Bill,
> >
> > again, I love your proposal!
>
>
> Does that mean you support the addition of this feature?
>
>
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com
>
>