On 1/26/12 6:07 AM, Sergey Beryozkin wrote:
>>
>>> http://java.net/jira/browse/JAX_RS_SPEC-155
>>>
>>
>> Sigh...Does anyone else in this group has an opinion re JAX_RS_SPEC-155
>> (duplicate interfaces representing the request headers) ?
>>
>
> Let me give it another try please.
>
> HttpHeaders [1] represents the request headers.
> RequestHeaders [2] represents the request headers.
>
> [1] is capable and also offers some useful constants.
> [2] is capable and better documented (at the top of the class) but
> duplicates [1], except for 2 extra methods.
>
> [2] is better 'aligned' with the RequestHeaders, name-wise, [1] is not
> having a 'Request'.
>
> I propose to either
>
> 1. keep [1] and remove [2]; please try to get convinced having both [1]
> & [2] as equal API citizens is not good at all, as [2] does not offer
> anything but the duplicate interface to the spec, with the two new
> methods (getDate() & getContentLength()) easily taken care of by
> HttpHeaders with the user having to call Integer.valueOf in the latter
> case - not a major issue IMHO
>
IMO, we should ditch RequestHeaders and ResponseHeaders and just have
HttpHeaders. Why is it ok to have methods in Request that make no sense
from the client side (i.e. all the validation methods), but not ok to
have methods in HttpHeaders that make no sense from a request or response?
We should be consistent. Either we have a unified interface hierarchy,
or we should add ClientRequest/ClientResponse and
RequestHeaders/ResponseHeaders interfaces. Personally, I'm split and
don't know what the optimal choice is. While its nice having a unified
hierarchy, its weird having methods behave differently depending on the
context you invoke them in.
BTW, Link header is also a request header. I use them extensively in
this manner for some of the Restful services I've written for JBoss.
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com