Looks great, especially having a single Response entity.
I'd propose to drop Response.bufferEntity() as it has no real use on the
server side, and on the client side, when one really needs to delay
processing a response, one simply can do Response.getEntity(...) and
keep whatever the result is until later.
The other thing is whether we can change Response.getMetadata()
returning MultivaluedMap<String, String> ? I think that in JAX-RS 1.1
Response is mainly processed by the server runtime and is not visible to
writers. In CXF Response is visible on the client side but that API is
not a standard one and besides I think dealing with
MultivaluedMap<String, String> is simpler anyway.
Cheers, Sergey
On 21/09/11 12:34, 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
--
Sergey Beryozkin
http://sberyozkin.blogspot.com
Talend - http://www.talend.com