Hi Santiago
On 22/08/12 18:27, Santiago Pericas-Geertsen wrote:
>
> On Aug 21, 2012, at 1:39 PM, Bill Burke wrote:
>
>>>> Perhaps we should stick to the standard attributes but leave the
>>>> capability to define extensions (not unlike arbitrary HTTP headers) and
>>>> let them worry about their syntax?
>>>
>>> This would be my preference, have standard attributes (as defined in
>>> RFC) supported explicitly, the parameters map is there to accommodate
>>> for the extensions if any.
>>>
>>>> I'd rather us not over-specify things
>>>> here; I'm on the fence with the attribute 'method', though.
>>>
>>> it does not harm but as I said I can see it working with the 'consumes'
>>> extension together, with the idea being that knowing the method and what
>>> the 'target' accepts, one can post/put to it.
>>>
>>> I'd drop the explicit support for 'produces', and either keep the
>>> explicit support for consumes + method or drop both. If we were to keep
>>> them then I'd also rename 'consumes' to 'accept' to give it a more
>>> JAX-RS-neutral name
>>>
>>
>> you don't need consumes either as the 'type' attribute covers it.
>
> Simplification of Link class:
>
> http://java.net/projects/jax-rs-spec/sources/git/revision/82749c50d691aaaebb4cd7897873e10af70197eb
>
> Convenience methods only for "type", "title" and "rel". Class no longer
> attempts to parse multi-valued params.
I wonder if MutivaluedMap should stay ? That will let Link handle
extensions with multivalued parameters, even if I guess in many cases it
will not be the case, but if we start seeing the cases with 'rel' having
multiple values then MultivaluedMap can help, with getRel() implying in
such cases something like get the first rel value, etc
Cheers, Sergey
>
> -- Santiago
>