Marc Hadley wrote:
> On Jun 20, 2008, at 4:37 AM, Paul Sandoz wrote:
>>
>> I think the issue here is that the media type set by the resource
>> class is not an acceptable media type.
>>
>> If the Accept header was:
>>
>> Accept : application/bar, application/foo
>>
>> then the media type returned for the Content-Type header would be
>> "application/foo" and that media type would be passed to the
>> MessageBodyWriter.writeTo().
>>
>> I think the the case you present there are a number of choices:
>>
>> 1) Return an not acceptable response, plus see the thread titled
>>
>> "status 406 if return object not serializable for POST, PUT,
>> DELETE"
>>
>> 2) Ignore the client accept header.
>>
>> 3) It is an error.
>>
> I'd prefer:
>
> 4) Serialize the Response as normal and assume the application know what
> it is doing.
>
> As Stephan pointed out its OK to return an unacceptable media type in
> some circumstances
It is the circumstances i am wondering about :-)
> and I don't think the runtime should be getting in
> the way to prevent this. Maybe its my libertarian leanings showing
> through but I think the job of the framework is to route the request to
> a matching method and serialize whatever response is returned, I don't
> think we should be going to extraordinary lengths to police applications.
>
>>
>> There is also another case:
>>
>> @ProduceMime({"application/bar", "application/foo"})
>> void Response get() {
>> return response.ok().
>> type(""application/baz").entity(someEntity).build();
>> }
>>
>> IMHO i think this should be an error because it contradicts the
>> declaration in @ProduceMime.
>>
> I prefer 4 above, no error just serialize the application/baz response.
>
I suspect that these cases are more likely to be performed in error than
a conscious decision to return an unacceptable media type.
Paul.
--
| ? + ? = To question
----------------\
Paul Sandoz
x38109
+33-4-76188109