Hi Santiago
sorry for a delay
On 19/10/11 15:52, Santiago Pericas-Geertsen wrote:
>
> On Oct 19, 2011, at 9:42 AM, 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
>
> In a way, yes. But the whole GenericEntity business is because of Java's type erasure; if we were designing an API for a different language, we would likely not have this problem. My point being, Java is part of our domain problem IMO.
>
>> 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.
>
> Could you elaborate this more? I think you may be on to something here. Are you saying that by making Response generic we are encouraging developers to return collections?
Yes to some extent. One of the patterns which I'm personally observing
is that users would like to take on the existing code which can be
heavily generilized and turn it as is into the RESTful service, without
attempting to change anything.
I think it's a valid case but such a code has more chances to survive
the changes if beans are involved. This is somewhat off topic, but
either way, complicating signatures involving Response to let users type
List<Bar> seems unwarranted - we have GenericEntity for users who who'd
like to keep returning List<Bar>. Besides, as Marek noted in the linked
JIRA's comments, it would make a case where a single method returns
different representations awkward to deal - users would have to
introduce <?> etc in order to avoid annoying warnings, etc.
> As for List<Bean>, doesn't JAXB define a bean to XSD mapping? (Apologies if I missed your point completely :)
>
Sorry, I'm showing my JAXB ignorance here :-). Given two methods, one
returning Response<List<Bean>> and the other Response<List<Bean>>, how
can a user document to the consumers the schema of elements returned by
both methods ? I guess who type List<Bean> won't care much, so I as
said, supporting Response<List<String>> makes it even easier for users
not to be concerned
Sergey
> -- Santiago
>
>>
>> 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
>
--
Sergey Beryozkin
http://sberyozkin.blogspot.com
Talend - http://www.talend.com