[occi-wg] About deleting a resource and what to return

[Tino Vazquez]

That is great. Thanks Sam.

--
Constantino Vázquez, Grid Technology Engineer/Researcher:
http://www.dsa-research.org/tinova
DSA Research Group: http://dsa-research.org
Globus GridWay Metascheduler: http://www.GridWay.org
OpenNebula Virtual Infrastructure Engine: http://www.OpenNebula.org



On Tue, Oct 20, 2009 at 1:20 PM, Sam Johnston <samj at samj.net> wrote:
> On Tue, Oct 20, 2009 at 12:53 PM, Tino Vazquez <tinova at fdi.ucm.es> wrote:
>>
>> Hi all,
>>
>> I have a doubt regarding the spec. In the OpenNebula implementation,
>> whenever a resource is deleted we return a confirmation message with a
>> 200OK status, but I don't think this is completely adecquate. As the
>> spec is not clear in this aspect (or I couldn't figure it out) I would
>> like to ask which would be the best way to proceed.
>>
>>  Shall we return nothing but the status, the representation of the
>> deleted object or rather just the ID of the deleted object? What do
>> you think.
>
> Let's ask RFC 2616:
>
>    9.7 DELETE
>
>    The DELETE method requests that the origin server delete the resource
>
>    identified by the Request-URI. This method MAY be overridden by human
>    intervention (or other means) on the origin server. The client cannot
>    be guaranteed that the operation has been carried out, even if the
>
>    status code returned from the origin server indicates that the action
>    has been completed successfully. However, the server SHOULD NOT
>    indicate success unless, at the time the response is given, it
>    intends to delete the resource or move it to an inaccessible
>
>    location.
>
>    A successful response SHOULD be 200 (OK) if the response includes an
>    entity describing the status, 202 (Accepted) if the action has not
>
>    yet been enacted, or 204 (No Content) if the action has been enacted
>    but the response does not include an entity.
>
>
>    If the request passes through a cache and the Request-URI identifies
>    one or more currently cached entities, those entries SHOULD be
>    treated as stale. Responses to this method are not cacheable.
>
> I've created an issue to make sure [something like] this gets added to the
> spec.
>
> Thanks for your bug report.
>
> Sam
>
>
>