jsr339-experts@jax-rs-spec.java.net

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

From: Bill Burke <bburke_at_redhat.com>
Date: Thu, 22 Mar 2012 10:38:31 -0400

On 3/21/12 5:07 PM, Marek Potociar wrote:
[snip]
>> In my experience on the Resteasy side, filters rarely wrap i/o streams. They either add/remove headers or abort/redirect request/responses. What I found that is the i/o stream wrapping happens in MessageBodyReader/Writer interceptors. This is because reading/writing an entity is usually independent of whether this is happening on the client or server while abortion/redirection is specific to its context.
>
> Ok, makes sense. What I am only trying to point out is that reader/writer interception can be substituted with a filter wrapping the input stream. Arguably, R/W interceptors make it more convenient and suitable for common (client/server) use cases.
>

I see your point. Either we have less spec interfaces and the user has
to write more code, or, more interfaces and the user has to write less
code. There's trade-off either way...

But...

The client side still has weird response flows (which is solve by
ReaderInterceptor). Specifically, that you can't guarantee the
app-developer will ever read the entity, but you still may want to
intercept the response. An example is a client cache, where a
ResponseFilter will want to cache the bits received from the server
whether or not the app-code decides to read the entity. IMO, this is
not dissimilar from the PreMatch/PostMatch filter.



>> Currently, I just don't see how you could *not* have the general interceptor architecture we currently have based on the requirements I spelled out last year:
>>
>> http://bill.burkecentral.com/2011/05/24/interceptors-in-jax-rs-2-0/
>>
>> But, I do think the API has room for improvement.
>
> I was thinking about a possibility to let filters manipulate reader/writer interceptor chains (add/remove interceptors). Would that make sense to you?

What is the use case for this? Adding/removing interceptors at runtime?
  Isn't it a feature that could be added later on in JAX-RS 2.1?



>> A 3rd disadvantage of the current API is that some methods have different behavior in different contexts.
>
> I can't recall any.

close(), bufferEntity() to name a couple. A lot of methods have a lot
of fine-print in the Javadoc too (like readEntity()).


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