On Nov 3, 2012, at 11:29 PM, Jan Algermissen <jan.algermissen_at_nordsc.com> wrote:
> Hi,
>
> playing around with Link I realize that it makes me 'work around' to achieve most basic use cases:
>
> - I often only want the URI of a given resource class or sub
> resource; since Link building requires me to pass a rel value
Have to correct myself here, because fromResourceMethod() provides a version without required rel value.
What is missing for me is
fromResource(Class<?> resource)
in addition to
fromResource(Class<?> resource,String rel)
(I have been confused a little because the whole thing does not really work in whatever JAX-RS 2.0 version comes with Glassfish b61.)
Jan
> I have to work with dummy values (e.g. "norel") or pass in null
> (if that is even possible).
> Both leads to 'strange' code. I think we should have Links and
> means of link building without requiring a rel value.
>
> - The idea to set the 'type' parameter per default makes the default
> toString() behavior emphasize a bad-practice. (Putting in type
> information might seem like a good idea to most people, but it really
> is against the idea that REST focusses on deferring such information
> to the actual request/response.)
>
> I think we should have another method besides toString() for generating
> link header values that include 'type' and make toString() exhibit
> 'correct' behavior.
>
> - Using 'type' information as the source for setting 'Accept' when
> calling Invocation.Builder#invocation(Link) is also something that
> leads away from RESTful design more than it leads towards it.
> Clients set 'Accept' based on *their* intentions and capabilities.
> That is, for example, why Browsers set 'Accept: image/*" or similar
> when following an <img src=""> link and what that link does not and does
> not need to provide any information about the media type of the image.
> THAT IS A RUNTIME ISSUE.
>
>
> Bottom line, with 'Link' for the first time the default behavior of JAX-RS goes against REST principles. Misguiding developers.
>
> (The built in support for application/xml and application/json has been misguiding since day one but at least it cleanly gets out of your way when you are doing RESTful systems. The application/xml and application/json entity providers are very often a quick win if you simply want XML over HTTP stuff, but they do not make me write strange code to do RESTful stuff).
>
> I recommend to rework 'Link' to naturally allow both, the quick wins some people like and RESTful design, too.
>
> Jan
>
>
>
>
>
>
>