Hi Marc,
> I think I prefer returning the error so its clear that something went
> wrong.
the primary action (create/change/delete the resource) does NOT went
wrong, only the serialization of the object to return.
> 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?
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.