I think I prefer returning the error so its clear that something went
wrong. 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).
Marc.
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.
>
> best regards
> Stephan
>
> ---------------------------------------------------------------------
> 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.