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.
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 Conflict
>>
>> The 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. 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)
>
> ************************************************************************
