On Oct 23, 2012, at 3:12 PM, Markus KARG wrote:
>>>> 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.
>>>>
>>>> -- Santiago
>>>
>>> What if you must write a JAX-RS client for an existing service that
>>> actually is sending multiple same-name Links?
>>>
>>> What if you must re-write a service using JAX-RS that already had
>> such
>>> an API and you must not break it for beakwards compatibility?
>>>
>>> We cannot say "sorry folks, Santiago thought nobody will need it, so
>>> do not use JAX-RS for it", as long as the RFC allows it.
>>>
>>> Also, I do not see any problem to simply write "getLinks()[0]" or
>>> "getLinks(0)" or "getLinks().next()" etc.
>>>
>>
>> Please, correct me if I'm wrong, but based on this thread I thought the
>> plan is to keep the convenience getLink(String rel) method to return
>> the first value of getLinks(String rel) method, which we would also
>> keep.
>
> Seems this must be some kind of misunderstanding. What I proposed was that
> we *replace* getLink by getLinks as Santigo didn't want an *additional*
> method. So I did not miss something. Anyways, so do we all agree that in the
> end the user will have the following to methods?
>
> .getLink(String rel) AND .getLinks(String rel)?
No, we don't, that is the point. There's a getLink(String) and there's a getLinks() already there that returns all of them.
>
>> So your sarcasm seems unnecessary and based on not following the
>> discussion carefully.
>
> Sarcasm is never "necessary" (I wonder how a situation would look like where
> it *is*) but it is always a kind of art of poetry and humor and personal
> style to express. If you are not used to it, do not understand it, or do not
> like it, I swear I will herbey abstain from any sense of humor for the rest
> of the EG. ;-)
Yes, please abstain. Especially when there's already a getLinks() that can be used in that much-less-common case.
-- Santiago