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

[jsr339-experts] Re: Proposal for merging HttpRequest/HttpResponse with the existing Request/Response API

From: Bill Burke <bburke_at_redhat.com>
Date: Wed, 21 Sep 2011 15:21:21 -0400

My only problem with not having a separate client and server class
hierarchy is that you'll have a lot of methods that don't make sense
when you're on a client or vice versa.

The fact that Response was an abstract class to begin was a bad design
decision. We should avoid doing this sort of thing for any other new class.

As for the details, well, you've already shown you're much better class
designers than me so I wouldn't want to inject any suggestions there.

On 9/21/11 7:34 AM, Marek Potociar wrote:
> Hello experts,
>
> please review the proposed change for merging HttpRequest and HttpResponse into the existing JAX-RS 1.x Request/Response
> API:
> http://java.net/projects/jax-rs-spec/sources/git/revision/8fd5db313234854b3b3e711d66f2073996e7d34a
> (Please ignore the listed spec text files and focus on the API)
>
> In particular the change consists of removing the HttpRequest and HttpResponse interfaces and *adding new methods* to the
> - Request interface
> - Response abstract class
> - Response.ResponseBuilder abstract class
>
> The proposal aims for reducing the confusion, simplifying things and cleaning up the overlapping concepts in the API.
>
> While the proposed changes introduce a risk of BW incompatibility, the problem is mainly affecting JAX-RS implementation
> providers, which does not seem to be an issue itself. However, although we don't expect any users to extend and
> implement the existing req/resp API classes, we cannot be sure if we did not miss any important or widely used use case,
> so we would like to ask for your cooperation in reporting any such use cases presently used in a production by either
> you or your clients/community. Please, be as specific as possible with each such use case.
>
> FWIW, we have already checked our intent within the JavaEE architects and spec leads group and while personal opinions
> of individual spec leads are divided, we are free to proceed with the change at our own discretion. Also, we would
> certainly not set a precedent - some other APIs already made similar changes in the past.
>
> I am looking forward to your feedback.
>
> Thank you,
> Marek

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