Hi
On 13/03/13 14:37, Marek Potociar wrote:
> Hi Sergey,
>
> We're talking about core, "low level" API being used here. Let's not try to prevent potential failures by making spec too complex without any practical gain on the user end.
>
sure; I guess this might be open for another review further down the
line if needed
Sergey
> Marek
>
> On Mar 13, 2013, at 3:20 PM, Sergey Beryozkin<sberyozkin_at_talend.com> wrote:
>
>> Hi
>>
>> We've talked about it before, in context of the exception mappers mapping the exceptions to Responses with non empty entities,
>>
>> example, the client Accepts application/xml, the server throws an exception, the mapper maps it to
>>
>> Response.status(400).type("text/plain").entity("Bad response").build().
>>
>> and this is exactly what the client should get back despite expecting only XML.
>>
>> However, consider that either the application code or even the exception mapper does
>>
>> Response.status(200).type("application/json").entity(someEntityBean).build().
>>
>> This is clearly an error that is better be detected by the server runtime, before the client code like "client.get(StreamSource.class)" reports something like "{" is not allowed in XML, etc.
>>
>> Should the spec say that if Response status is>=400 and the entity is not null then this Response media type whatever it is, is used; otherwise, if Response is 200, the entity is not null, then the runtime should treat its media type the same way it treats @Produces ?
>>
>> Sergey
>