On Jun 13, 2008, at 10:02 AM, Stephan Koops wrote:
>> AFAIK, HTTP doesn't make any guarantees about whether any work was
>> done even if you get an error status (IOW, a method isn't
>> transactional).
> ok, but why not make it better as the guarantee?
>
I don't think its possible when the method claims to be able to
produce */* and the class of the response entity body isn't known
until runtime. In that case its always possible that the client will
ask for some media type that can't be produced from the class of the
response entity.
From an application point of view, this is easy to fix - just declare
the supported media types with @ProduceMime and make sure you have a
MessageBodyWriter for the types you return from the method.
Marc.
> Stephan
>> On Jun 12, 2008, at 4:27 PM, Stephan Koops wrote:
>>>
>>> if a client calls a non-safe method (POST, PUT, DELETE, ...), the
>>> corresponding resource method is called and returns an object, but
>>> no message body writer for this object considering the accepted
>>> media types could be found, the server will return 406 (not
>>> acceptable; see section 3.8 of spec). The action was done, but the
>>> client gets the message, that the request could not be fulfilled.
>>> Not good ...
>>>
>>> RFC 2616 says in a note to status 406 (http://tools.ietf.org/html/rfc2616#section-10.4.7
>>> ), that "HTTP/1.1 servers are allowed to return responses which
>>> are not acceptable according to the accept headers sent in the
>>> request. In some cases, this may even be preferable to sending a
>>> 406 response. User agents are encouraged to inspect the headers of
>>> an incoming response to determine if it is acceptable." I think,
>>> this are cases, where it is preferable to not send an 406 response.
>>>
>>> Perhaps it is useful to return 406 only for GET and HEAD, and
>>> otherwise - if no message body writer could be found - the status
>>> given by the javax.ws.rs.core.Response (or 200) with an text
>>> message or that as "text/plain" or something like that.
>>> To not hard code GET and HEAD (whatever safe methods may exist
>>> (PROPFIND?||)) it could be useful to add an boolean flag "save" to
>>> @HttpMethod which indicates, if the method is safe of changes
>>> anything of the server state. Perhaps it is useful to give no
>>> default, so that an implementor of a method designator must
>>> decide, which value o give here. If we want to give a default
>>> value, it should be "not save" to be sure.
>>> If there is no default value for safe, the attribute
>>> @HttpMethod.value could perhaps renamed to "name" or something
>>> like that. That's better to read than value in method designator
>>> definition.
>>>
>>> The same problem occurs, if a message body writer throws an
>>> WebApplicationException. Semanticly the status given by the method
>>> (or 200) must be returned.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_jsr311.dev.java.net
> For additional commands, e-mail: users-help_at_jsr311.dev.java.net
>
---
Marc Hadley <marc.hadley at sun.com>
CTO Office, Sun Microsystems.