Subject: [scim] HTTP Status code for successful DELETE

From: Matt Randall <[email-masked]>
Date: Fri, 17 Jan 2014 13:09:57 -0600

Section 3.4 (Deleting Resources) of the 1.1 and 2.0 specification provides
the example of a 200 OK response for a successful delete.  The
specification does not explicitly indicate whether a 200 or 204 should be
returned.  Depending on whether a server is serving additional header
metadata associated with that operation, it would seem that either could be
a valid response.  We've found certain implementations of SCIM clients
expect an exact value of 200 OK.

My questions:

- Should this be clarified in the specification?
- Should 204 also be accepted by SCIM clients in response to a successful
DELETE operation?

Thank you.

---

From: Julian Reschke <[email-masked]>
Date: Fri, 17 Jan 2014 20:31:04 +0100

On 2014-01-17 20:09, Matt Randall wrote:
> Section 3.4 (Deleting Resources) of the 1.1 and 2.0 specification
> provides the example of a 200 OK response for a successful delete.  The
> specification does not explicitly indicate whether a 200 or 204 should
> be returned.  Depending on whether a server is serving additional header
> metadata associated with that operation, it would seem that either could
> be a valid response.  We've found certain implementations of SCIM
> clients expect an exact value of 200 OK.
>
> My questions:
>
> - Should 204 also be accepted by SCIM clients in response to a
> successful DELETE operation?
> ...

Do not profile HTTP. Both are success codes. Both are ok.

Best regards, Julian

---

From: Erik Wahlström <[email-masked]>
Date: Mon, 20 Jan 2014 13:21:56 +0000

Hi,

I’ve been thinking about this for a while now and it feels like we already have started to profile HTTP. Even through I kinda like the concept of not messing with it.

An examples is that the spec define that a create should be a 201 Created. An un-profiled spec would also accept 100 Continue. Another example is that a PATCH MUST return either 200 or 204 No Content according to the spec.

In the line of keeping it as simple as possible, an early and important design decision, to implement (even in very thin clients and in javascript), I think it’s important to define things like this rather hard. That helps the clients always know what to expect.

We talked a bit about response codes for DELETE before http://www.ietf.org/mail-archive/web/scim/current/msg01390.html

And we also have a ticket for it https://tools.ietf.org/wg/scim/trac/ticket/39

I prefer to define that a server MUST return a 204 No Content on response to a successful DELETE request. That means, I’m pro profiling.

/ Erik

On 17 Jan 2014, at 20:31, Julian Reschke <[email-masked]<mailto:[email-masked]>> wrote:

My questions:

Best regards, Julian
_______________________________________________
scim mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/scim

---

From: Julian Reschke <[email-masked]>
Date: Mon, 20 Jan 2014 14:39:29 +0100

On 2014-01-20 14:21, Erik Wahlström wrote:
> Hi,
>
> I’ve been thinking about this for a while now and it feels like we
> already have started to profile HTTP. Even through I kinda like the
> concept of not messing with it.
>
> An examples is that the spec define that a create should be a 201
> Created. An un-profiled spec would also accept 100 Continue. Another

Yes and no. 100 Continue is not a final status.

And no, don't profile.

> example is that a PATCH MUST return either 200 or 204 No Content
> according to the spec.

What if the PATCH request created a resource?

> In the line of keeping it as simple as possible, an early and important
> design decision, to implement (even in very thin clients and in
> javascript), I think it’s important to define things like this rather
> hard. That helps the clients always know what to expect.

That's exactly the wrong approach. You're basically inventing a profile 
without the need to do so. This has lots of disadvantages; for instance, 
you restrict yourself to HTTP libs/impls that you can control at that 
detail level, the protocol gets harder to evolve, it becomes super-hard 
to have resources implement multiple HTTP-based protocols at the same 
time, and furthermore intermediaries might get in the way.

> We talked a bit about response codes for DELETE before
> http://www.ietf.org/mail-archive/web/scim/current/msg01390.html
>
> And we also have a ticket for it
> https://tools.ietf.org/wg/scim/trac/ticket/39
>
> I prefer to define that a server MUST return a 204 No Content on
> response to a successful DELETE request. That means, I’m pro profiling.
> ...

Don't. We've had this discussion multiple times in the APPS area already 
:-).

Best regards, Julian

---

From: Phil Hunt <[email-masked]>
Date: Sat, 25 Jan 2014 17:51:52 -0500

Phil

> On Jan 20, 2014, at 8:39, Julian Reschke <[email-masked]> wrote:
> 

Umm why or why not is ANY rest spec a profile of http?
> What if the PATCH request created a resource?

In scim i am not aware of this possibility. Patch can only change attributes of existing resources.

That seems pretty consistent with a lot of rest approaches. 
> That's exactly the wrong approach. You're basically inventing a profile without the need to do so. This has lots of disadvantages; for instance, you restrict yourself to HTTP libs/impls that you can control at that detail level, the protocol gets harder to evolve, it becomes super-hard to have resources implement multiple HTTP-based protocols at the same time, and furthermore intermediaries might get in the way.

See above regarding rest apis. 
> Don't. We've had this discussion multiple times in the APPS area already :-).
> 
> Best regards, Julian
> [email-masked]

---

From: Julian Reschke <[email-masked]>
Date: Sun, 26 Jan 2014 10:40:22 +0100

> Umm why or why not is ANY rest spec a profile of http?

There are different layers that can be profiled.

> In scim i am not aware of this possibility. Patch can only change attributes of existing resources.

Attributes of?

But yes, if PATCH never creates a resource than a 201 will not be 
returned. However the same isn't necessarily true for new 2xx codes.

Best regards, Julian

---

From: Phil Hunt <[email-masked]>
Date: Sun, 26 Jan 2014 09:36:29 -0800

It seems to me that SCIM as a REST API that is a highly profiled layer on top of HTTP in both API and common attribute and object schema. The objective of which is specificity to create highly interoperable cross domain communication of well specified objects. 

I agree that at no time should SCIM conflict with the http layer. However, for items that remain unspecified or unclear (eg redirects and use of some result codes), the spec should be sufficiently specific to achieve interop and no more. 

Based on some of your comments, we might need to register new codes -- particularly for attribute level issues. My guess is resource issues are well specified by http. Your comment about http patch is interesting in this regard.  

Phil

> On Jan 26, 2014, at 1:40, Julian Reschke <[email-masked]> wrote:
> 
> But yes, if PATCH never creates a resource than a 201 will not be returned. However the same isn't necessarily true for new 2xx codes.
> 
>> ...
> 
> Best regards, Julian
>