On Aug 23, 2012, at 6:37 PM, Sergey Beryozkin <sberyozkin_at_talend.com> wrote:
> Hi Santiago
> On 23/08/12 14:00, Santiago Pericas-Geertsen wrote:
>> Hi Sergey,
>>
>> On Aug 22, 2012, at 5:13 PM, Sergey Beryozkin wrote:
>>
>>>> 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
>>
>> Thanks for reviewing this. The problem with multi-valued parameters is that, in general, we don't know how to parse/serialize them. We do for "rel" because it is the defined in the RFC, but not for arbitrary extensions like "produces" and "consumes". The generic mechanism of using one or more space chars as separators does not work, and this is what prompted the change.
>>
>> By using a single-valued map, we push the problem of value interpretation to the application and simplify the framework code. If we don't, we'll need a way to plug parsers/serializers for extension parameters, and that seems like over-engineering for a first cut of Link.
>>
> We could've still used MultivaluedMap for presenting multiple 'rel' values given the way it can be parsed is known, but I agree it will be more consistent to let the application deal with all the parameters the same way,
I'd suggest we rename "getRel()" to "getRelationString()" and add a new "List<String> getRelations()" method.
Marek
>
> thanks, Sergey
>> -- Santiago
>>
>>
>