Re: [scim] Clarification on body request for DELETE

We've been discussing that 202 should generally be interpreted as, transaction is syntactically valid but pending completion (e.g. an approval workflow). It seems there is a need to do this with all SCIM operations.

Successful immediate completion would be status 200 or potentially 204.  Is there any reason for a SP to indicate for example that an entity wasn't actually deleted, but rather suspended (e.g. because the SP has a tombstone feature to preserve UUIDs)?

Phil

@independentid
www.independentid.com
phil.hunt@oracle.com

On 2013-03-27, at 11:10 AM, Kelly Grizzle wrote:

> The SCIM API spec is not entirely clear here.  According to RFC 2616, the DELETE operation should work like this:
>  
>    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.
>  
> I can’t think of anything interesting for SCIM to return in a response body, so my vote would either be a 200 with an empty response (or just a message) or a 204 with no response body.  Perhaps we should open an issue to clarify this.  Thoughts?
>  
> --Kelly
>  
> From: scim-bounces@ietf.org [mailto:scim-bounces@ietf.org] On Behalf Of Alexandre Santos
> Sent: Wednesday, March 27, 2013 11:04 AM
> To: scim@ietf.org
> Subject: [scim] Clarification on body request for DELETE
>  
> The spec for PUT says "3.3.1...  Unless otherwise specified a successful PUT operation returns a 200 OK response code and the entire Resource within the response body"
> For POST: "3.1...  the response body MUST contain the newly created Resource."
> For DELETES it says "
> 3.4.  Deleting Resources
> 
> Consumers request Resource removal via DELETE. Service Providers MAY choose not to permanently delete the Resource, but MUST return a 404 error code for all operations associated with the previously deleted Id. Service Providers MUST also omit the Resource from future query results. In addition the Service Provider MUST not consider the deleted resource in conflict calculation. For example if a User resource is deleted, a CREATE request for a User resource with the same userName as the previously deleted resource should not fail with a 409 error due to userName conflict.
> "
>  
> My question is, what (if anything at all) should be returned in the response body as a result of a successful DELETE operation.
>  
> Thanks,
> Alex Santos
>  
> _______________________________________________
> scim mailing list
> scim@ietf.org
> https://www.ietf.org/mailman/listinfo/scim