Skip to main content

[jsr339-experts] Re: Consistency and awkwardness issues with Request/Response/Filter API

  • From: Bill Burke <bburke@...>
  • To: jsr339-experts@...
  • Subject: [jsr339-experts] Re: Consistency and awkwardness issues with Request/Response/Filter API
  • Date: Wed, 29 Feb 2012 11:13:15 -0500



On 2/29/12 6:39 AM, Sergey Beryozkin wrote:
Hi Bill
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):

https://github.com/patriot1burke/jaxrs2-proposal-2-24-12

* Clients don't use the Request interface at all. Only within a client
filter.

* 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
representation.
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.


If there is an entity, then the container cannot automatically close the InputStream until the entity is read. There are times when the client does not care about the entity (i.e. an error response). Are you suggesting that the client has to read the entity even if it doesn't care about it?

* Header values aren't always objects or strings. On the server side,
Request headers are strings, on the client side, they are Objects. Vice
versa with Response headers.

I think Objects (on the client or server sides) should only be settable
when headers are set initially. On the get side - should always be strings.


Seriously you think that? For one, you don't think a filter will want to add a header to an outgoing request or resopnse? You want to require them to marshal these headers into String before adding them? You are also saying filters will have to unmarshal the header value before interacting with it? Both of these are akin to marshalling the request or response before it is finished being built.

Not to mention that MessageBodyWriters already require header values as java.lang.Objects. Be consistent with MessageBodyWriters.

http://java.net/jira/browse/JAX_RS_SPEC-176

* Server-side deployment scanning is unusable if you have client-only
Request or ResponseFilters in your classpath:

http://java.net/jira/browse/JAX_RS_SPEC-170

This will require extra metadata (annotation or otherwise).

Not worried about this one :-)


Well, you should worry about it as it is an issue. The examples/ folder in the spec already has examples of client-only filters. Currently there is no way to designate these filters as client-only, and these filters will end up in the server filter chain if scanning is turned on.


* 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


Well, for one, I strongly oppose header values always represented as Strings. HttpHeaders return header value as Strings which isn't compatible with a client request header value which can be java.lang.Object.



--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com


[jsr339-experts] Consistency and awkwardness issues with Request/Response/Filter API

Bill Burke 02/28/2012

[jsr339-experts] Re: Consistency and awkwardness issues with Request/Response/Filter API

Sergey Beryozkin 02/29/2012

[jsr339-experts] Re: Consistency and awkwardness issues with Request/Response/Filter API

Bill Burke 02/29/2012
 
 
Close
loading
Please Confirm
Close