>
>> 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
2. Keep [2] but deprecate [1] and copy constants identifying
request-related constants from HttpHeaders to RequestHeaders (and from
HttpHeaders to ResponseHeaders for response-related constants)
Either of these options works for me, and while I prefer [1] at least
with [2] we will have spec being more specific about having two
duplicate interfaces.
I'd like to encourage the experts to have another open look at this issue.
There's also an issue of extending such interfaces in the future but
IMHO it's a separate discussion, and the whole approach will need to be
consistent
Cheers, Sergey
[1]
http://java.net/projects/jax-rs-spec/sources/git/content/src/jax-rs-api/src/main/java/javax/ws/rs/core/HttpHeaders.java?rev=acfb7ecf63799ab6d726ad206bcd6eb49e9142ee
[2]
http://java.net/projects/jax-rs-spec/sources/git/content/src/jax-rs-api/src/main/java/javax/ws/rs/core/RequestHeaders.java?rev=acfb7ecf63799ab6d726ad206bcd6eb49e9142ee
> Sergey