Hi all,
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.
best regards
Stephan