Il 23/03/2011 12:57, Greg Brown ha scritto:
Returning a response body from a PUT is not supported. PutQuery extends Query<Boolean> and returns a value of true when the query creates a resource on the server and false when it does not (i.e. updates an existing resource). I'd suggest returning an HTTP 409 and passing any additional information in a *response header*.
For HTTP 409 the standard recomends to put additional information in the body:
10.4.10 409 ConflictThe request could not be completed due to a conflict with the current state of the resource. This code is only allowed in situations where it is expected that the user might be able to resolve the conflict and resubmit the request. *The response body* SHOULD include enough information for the user to recognize the source of the conflict.
Don't you think is more appropriate to modify the execute method in Query.java to permit the return of the response body for every kind of query and not only for the GET?
Ciao Stefano
On Mar 22, 2011, at 3:21 PM, Dr. Stefano Sancese wrote:Hi, I'm developing a RESTFul application using Pivot for the client side.No problem with the GET, but now I'm working on PUT and I have a question:What if the PUT can not be complete, for example because there is an unique key constrain on a field that throws a duplicated error?In this case I'd like to show to the user why the request can not be completed and I wolud like to use the respons body for an extended message.I digged the source and I found this code in web/src/org/apache/pivot/web/Query.java (the class PutQuery extends) the following code at line 499:// Read the response body if (*method == Method.GET* && status == Query.Status.OK) { InputStream inputStream = null; try { inputStream = connection.getInputStream();value = serializer.readObject(new MonitoredInputStream(inputStream));} finally { if (inputStream != null) { inputStream.close(); } } }So it looks like that only for the GET query the response body is read. From http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10.4.10:10.4.10 409 ConflictThe request could not be completed due to a conflict with the current state of the resource. This code is only allowed in situations where it is expected that the user might be able to resolve the conflict and resubmit the request. The response body SHOULD include enoughinformation for the user to recognize the source of the conflict. Ideally, the response entity would include enough information for the user or user agent to fix the problem; however, that might not be possible and is not required.Conflicts are most likely to occur in response to a PUT request. For example, if versioning were being used and the entity being PUT included changes to a resource which conflict with those made by an earlier (third-party) request, the server might use the 409 response to indicate that it can't complete the request. In this case, *the response entity *would likely contain a list of the differences between the two versions in a format defined by the response Content-Type.I infer that, in case of error, the server can send a response. Am I wrong? Ciao Stefano -- Dr. Stefano Sancese WatchGuard Certified System Professional -http://www.watchguard.com Socio Clusit - Associazione Italiana per la Sicurezza Informatica ************************************************************************ In God we trust, all others we monitor (National Security Agency) ************************************************************************
-- Dr. Stefano Sancese WatchGuard Certified System Professional - http://www.watchguard.com Socio Clusit - Associazione Italiana per la Sicurezza Informatica ************************************************************************ In God we trust, all others we monitor (National Security Agency) ************************************************************************
smime.p7s
Description: S/MIME Cryptographic Signature
