And as I said, what happens on the client side, if we have TypeLiteral
response.get(new TypeLiteral(...)) will work anyway, so having two ways
for getting to List<Bean> seems redundant
Sergey
On 19/10/11 14:42, Sergey Beryozkin wrote:
> That is one side of the story and on its own it's good. It's purely Java
> - nothing to do with writing RESTful services
>
> The other one is that the spec is about facilitating writing RESTful
> services and trying hard to make it easy for users write the code which
> is unlikely to produce an interoperable and difficult to document data
> (ex, how will a schema element representing a List<Bean> wrapper will
> look like) does not look like a good idea to me.
>
> Cheers, Sergey
>
> On 19/10/11 14:34, Santiago Pericas-Geertsen wrote:
>>
>> On Oct 19, 2011, at 7:41 AM, Sergey Beryozkin wrote:
>>
>>> Thanks, so I'm wondering why would we want to make an effort and let
>>> users write
>>>
>>> 'public Response<List<Bean>>'
>>
>> I think it's mostly for readability and tooling. Any form of static
>> tooling would benefit from the extra type information; and it's
>> arguably more readable for developers as well.
>>
>> We sort of went in this direction with WriteToHandlerContext<T> and
>> ReadFromHandlerContext<T>.
>>
>> -- Santiago
>>
>> PS: I think the first example in JAX_RS_SPEC-108 has a typo, and
>> should return Response.
>>
>>> What is a List<Bean> on the wire ? It can not be properly described.
>>> That of course can work, we can even customize easily the wrapper
>>> name, etc, but I'm not sure it's a spec level issue at all
>>>
>>> Cheers, Sergey
>>>
>>> On 19/10/11 12:29, Marek Potociar wrote:
>>>> See here for more explanation:
>>>> http://java.net/jira/browse/JAX_RS_SPEC-108
>>>>
>>>> Marek
>>>>
>>>> On 10/16/2011 06:09 PM, Sergey Beryozkin wrote:
>>>>> Hi
>>>>>
>>>>> On 14/10/11 17:20, Marek Potociar wrote:
>>>>>> Hello experts,
>>>>>>
>>>>>> we've privately received some suggestions to make Req/Resp +
>>>>>> builders generic.
>>>>>>
>>>>>> + The advantage would be the type safety as well as potential to
>>>>>> preserve type information so that GenericEntity does
>>>>>> not have to be utilized directly (e.g. HTTP resource methods that
>>>>>> produce Response currently would be able to better
>>>>>> declare the actual response entity type, provided the entity types
>>>>>> produced share a common ancestor).
>>>>>>
>>>>>> - The main disadvantage I can think of is that generic
>>>>>> req/response processing would (if correctly typed) require the
>>>>>> extra "<?>" in many scenarios.
>>>>>>
>>>>>
>>>>> What advantage can that give to the client code, would that
>>>>> interfere with the use of TypeLiteral in Response.getEntity
>>>>> ? Personally I can live with the use of GenericEntity on the server
>>>>> side because IMHO the use of explicit collections is
>>>>> not in 'mainstream', it seems most users are happy with dealing
>>>>> with plain beans - those can be better validated,
>>>>> extended and described
>>>>>
>>>>> Cheers, Sergey
>>>>>
>>>>>> Thoughts?
>>>>>>
>>>>>> Marek
>>>
>>>
>>> --
>>> Sergey Beryozkin
>>>
>>> http://sberyozkin.blogspot.com
>>> Talend - http://www.talend.com
>>
>
>
--
Sergey Beryozkin
http://sberyozkin.blogspot.com
Talend - http://www.talend.com