users@jax-rs-spec.java.net

[jax-rs-spec users] [jsr339-experts] Re: Re: There could be more than one Link header for a given rel

From: Jan Algermissen <jan.algermissen_at_nordsc.com>
Date: Tue, 23 Oct 2012 16:53:29 +0200

On Oct 23, 2012, at 4:48 PM, Santiago Pericas-Geertsen <Santiago.PericasGeertsen_at_oracle.com> wrote:

>
> On Oct 22, 2012, at 12:53 PM, Markus KARG wrote:
>
>> As the RFC allows it, we have to support it. There is no need to add more
>> methods if we *replace* getLink by getLinks.
>
> -1
>
> If we do that, we'd be designing the API for the exception not the rule. In the majority of cases, you'd have a collection with a single element.
>

Yes, I agree - it's sort of a semantic Web use case, mostly :-)

Jan



> -- Santiago
>
>>
>>> -----Original Message-----
>>> From: Santiago Pericas-Geertsen
>>> [mailto:Santiago.PericasGeertsen_at_oracle.com]
>>> Sent: Montag, 22. Oktober 2012 15:31
>>> To: jsr339-experts_at_jax-rs-spec.java.net
>>> Subject: [jsr339-experts] Re: There could be more than one Link header
>>> for a given rel
>>>
>>>
>>> On Oct 21, 2012, at 4:13 AM, Jan Algermissen wrote:
>>>
>>>>
>>>> On Oct 21, 2012, at 12:29 AM, Jan Algermissen wrote:
>>>>
>>>>> Hi,
>>>>>
>>>>> AFAIK there can be more than one Link header value for any given
>>> rel. E.g. one could have
>>>>>
>>>>> Link: </a>; rel="describedBy"
>>>>> Link: </b>; rel="describedBy"
>>>>>
>>>>> given that
>>>>>
>>>>> Link getLink(String relation)
>>>>>
>>>>> Should (unfortunately) be something like
>>>>>
>>>>> Collection<Link> getLinks(String relation)
>>>>>
>>>>> Agreed?
>>>>>
>>>>> I'll check back on apps-discuss.
>>>>
>>>> Seems correct - there can be more than one link for any given rel:
>>>>
>>>> http://www.ietf.org/mail-archive/web/apps-
>>> discuss/current/msg07612.html
>>>>
>>>> Issue opened here:
>>>> http://java.net/jira/browse/JAX_RS_SPEC-276
>>>
>>> We had some discussions about this in the past (I'd need to look them
>>> up). I recall people thought this case was much less common and could
>>> be handled by Set<Links> getLinks() and some filtering, already in the
>>> API. I'm not strongly opposed to this addition, but there something to
>>> be said about keeping the number of methods to a minimum.
>>>
>>> -- Santiago
>>
>>
>