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
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