Re: [scim] Clarification on body request for DELETE

Phil ... I think the two thoughts you bring up are valid.  The 202 status code should probably be addressed as a part of issue #32, and the suspension vs. deletion could be addressed in issue #15.

From: scim-bounces@ietf.org [mailto:scim-bounces@ietf.org] On Behalf Of Phil Hunt
Sent: Wednesday, March 27, 2013 6:51 PM
To: Kelly Grizzle
Cc: scim@ietf.org; Alexandre Santos
Subject: Re: [scim] Clarification on body request for DELETE

Sorry, by "we" I meant I was discussing with my colleagues at Oracle. I don't want to imply that other members of the WG are in agreement or disagreement. I simply want to concur Oracle identified as an issue needing more discussion.  :-)

Phil

@independentid
www.independentid.com<http://www.independentid.com>
phil.hunt@oracle.com<mailto:phil.hunt@oracle.com>

On 2013-03-27, at 2:48 PM, Phil Hunt wrote:

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<http://www.independentid.com/>
phil.hunt@oracle.com<mailto: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> [mailto:scim-bounces@ietf.org] On Behalf Of Alexandre Santos
Sent: Wednesday, March 27, 2013 11:04 AM
To: scim@ietf.org<mailto: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<mailto:scim@ietf.org>
https://www.ietf.org/mailman/listinfo/scim

_______________________________________________
scim mailing list
scim@ietf.org<mailto:scim@ietf.org>
https://www.ietf.org/mailman/listinfo/scim