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

From: Bill Burke <>
Date: Tue, 06 Mar 2012 09:56:55 -0500

On 3/5/12 3:17 PM, Santiago Pericas-Geertsen wrote:
> On Mar 5, 2012, at 11:17 AM, Bill Burke wrote:
>> Give me a usecase where a filter implementation (other than logging) *WOULD* be shared between client and server. In my experience, it will usually be the case that you *cannot* share filters between client and server. For example, an authentication filter is server-only. A browser-like cache is client-only. In both of these examples, you would actually make the client or server unusable at runtime if they were shared by accident (like say via scanning).
>> All this is because the semantics of a RequestFilter are totally different from client and server. A RequestFilter on the server is reading and processing incoming requests. On the client, a RequestFilter is writing and sending outgoing requests. Sharing will occur mostly within Reader/Writer interceptors because the semantics of incoming/outgoing are encapsulated within these interfaces already.
> I understand your proposal now. At first glance, I thought you were proposing to split everything, including interceptors. I tend to agree with your observation about filters.
> I'm still not sure I prefer an API with more types to discern these cases in favor of a more general one with some illegal state exceptions. Need to think this through more. There's value in keeping the number of interfaces down.
> As for the scanning problem, I agree it's an issue that needs to be resolved one way or the other.

The thing is, with specific types, you're less likely to make a mistake
like forget a scoping annotation. Or, if somebody creates a client
library you want to include in your server app, what if they just
ignored the scoping annotations?

Plus, if you look at the proposal, it cleans up a few other
inconsistencies that I've whined about.

Bill Burke
JBoss, a division of Red Hat