On 28/02/12 17:20, Bill Burke wrote:
I just wanted to list all the inconsistencies and awkwardness with the
current Request/Response/Filter API and to suggest a different proposal
here (read the readme):
* Clients don't use the Request interface at all. Only within a client
* THere are methods that don't make sense on Request and Response
depending on the semantics:
- Request.selectVariant(), evaluatePreconditions(), etc. don't make
sense on the client side.
- Request.readEntity() methods don't make sense on the client side.
- Response.readEntity(), close(), and bufferEntity methods don't make
sense on the server side
So indeed it possibly make sense introducing a client side Request
As for Response, I do think that the close() method was redundant, one
can get the InputStream and close if needed but you also was keen on
having that method :-); indeed the semantics of close() on the server
side are not clear to me at all and as I indicated earlier on it might
interfere with other framework-specific features to do with calling
post-destroy methods on server resource classes.
* Header values aren't always objects or strings. On the server side,I think Objects (on the client or server sides) should only be settable
Request headers are strings, on the client side, they are Objects. Vice
versa with Response headers.
when headers are set initially. On the get side - should always be strings.
http://java.net/jira/browse/JAX_RS_SPEC-176Not worried about this one :-)
* Server-side deployment scanning is unusable if you have client-only
Request or ResponseFilters in your classpath:
This will require extra metadata (annotation or otherwise).
* On the server-side, we're changing how developers interact with
JAX-RS. Instead of HttpHeaders we want them to inject RequestHeaders or
a Request object.
I do want HttpHeaders be preserved as the main representation of the
request headers on the server side as having both HttpHeaders &
RequestHeaders does seem controversial to me, but I do not see why
replacing them with RequestHeaders changes the interaction pattern; as
for Request offering the reference to headers - this seems simply
another option as opposed to the pattern change
[jsr339-experts] Re: Consistency and awkwardness issues with Request/Response/Filter API