On 12/11/2013 7:53 AM, Marek Potociar wrote:
>
> On 08 Nov 2013, at 17:53, cowwoc <cowwoc_at_bbs.darktech.org
> <mailto:cowwoc_at_bbs.darktech.org>> wrote:
>
>> On 08/11/2013 7:15 AM, Marek Potociar wrote:
>>> Resource should represent a concept, not a particular representation
>>> of a concept. Resource should be identified by URI (or new content),
>>> not by content-type.
>>
>> You've convinced me. I've made the modification you suggested (@POST
>> on the collection), but I'd still like to be able to specify a
>> Content-Type with an empty request body (unless we figure out how to
>> get @Consumes to match the lack of Content-Type). Can I open a
>> feature request for this?
>
> I'm waiting for a confirmation from RedHat that they agree with the
> proposed change.
Okay. Is there an issue tracking this which I can subscribe to?
>>> We do not eliminate. Our mission, though, is to provide hight-level
>>> API that helps you design and implement your services according to
>>> the principles of REST (See JSR-311
>>> <http://jcp.org/en/jsr/detail?id=311#2>, section 2.1). As such, we
>>> are not going to make it simpler for anyone to do ugly stuff. One
>>> can use directly lower-level Servlet API if wants to do something
>>> non-RESTful with HTTP.
>>
>> 1. The definition of "ugly" is subjective.
>> 2. How are we supposed to use the lower-level Servlet API? Are you
>> expecting us to use a Servlet Filter to mutate the response after
>> Jersey sets it? Isn't it already too late at that point (the
>> stream is already flushed)? This also sounds like maintenance
>> hell for unit tests! If you'd really like to punt to the
>> lower-level Servlet API, there should be an (easy!) way for me to
>> translate a Jersey request/response to a Servlet request/response
>> within the same method (as opposed to using filters which require
>> me to spread the logic across multiple classes). The resulting
>> code has to be easy to maintain.
>>
I'm still waiting on an answer on how to make a request with a
ContentType but no body.
Thanks,
Gili