The status codes are pretty consistent. What is being affected are
related, aka, nested routes which always returned a 201 on DELETE. Any
delete on a resource returns a 204 if done immediately or 202 if its
queued. In some cases you have the option of specifying whether the
delete should be queued via the async query parameter.

On further review, there's a mix of return codes currently returned on
deletion.
Some end points that return 204's on delete(apps, buildpacks, spaces, orgs)
Some end points that return 201 (remove a route from an app, remove a
service binding from an app, remove a user from an org or a space)
The new asynchronous service deletion, returns a 202.
I agree it's a useful distinction and something to consider if we were to
address this issue on v2 endpoints.


On Wed, Oct 14, 2015 at 9:53 PM, John Feminella <jfeminella(a)pivotal.io>
wrote:

I agree that 201 is a bug; that's not mutually exclusive with being a
breaking API change. It should be fixed, but I'd consider doing that as
changing the API, too.

Also, on 204, have we considered whether returning 202 sometimes might
make sense? For instance, if the resource in question isn't actually
deleted yet and/or we can't guarantee that a successive GET on that
resource will return 404, then we IMO we should return HTTP 202 instead. In
that case, we are merely accepting the request to delete but we can't
guarantee deletion until some future point.

I think this is a useful distinction to make in a distributed system
because it tells other clients whether a successive GET on the same
resource could possibly work. But this also adds complexity that might not
be useful.

John Feminella
Advisory Field Engineer
✉ · jfeminella(a)pivotal.io
t · @jxxf
On Oct 14, 2015 21:09, "Dieu Cao" <dcao(a)pivotal.io> wrote:

Hi All,

Most of cloud controller api's v2 end points currently return a 201 on
delete.
I would like to get feedback on how the community would feel if we change
this to return a 204 No Content.

In some respects, this could be considered a backwards breaking change as
this behavior has existed for a while and it's possible some clients have
made accommodations for this bug such that if we were to change the return
code to 204, it might break clients expecting to get a 201.

However, this could also be considered a bug fix.
I lean towards considering this a bug and would like to fix this.

Thoughts? Concerns?
We do plan to address this as we move resources to v3 of the cc api.

-Dieu
CF CAPI PM

I agree that 201 is a bug; that's not mutually exclusive with being a
breaking API change. It should be fixed, but I'd consider doing that as
changing the API, too.

Also, on 204, have we considered whether returning 202 sometimes might make
sense? For instance, if the resource in question isn't actually deleted yet
and/or we can't guarantee that a successive GET on that resource will
return 404, then we IMO we should return HTTP 202 instead. In that case, we
are merely accepting the request to delete but we can't guarantee deletion
until some future point.

I think this is a useful distinction to make in a distributed system
because it tells other clients whether a successive GET on the same
resource could possibly work. But this also adds complexity that might not
be useful.

John Feminella
Advisory Field Engineer
✉ · jfeminella(a)pivotal.io
t · @jxxf

Hi All,

Most of cloud controller api's v2 end points currently return a 201 on
delete.
I would like to get feedback on how the community would feel if we change
this to return a 204 No Content.

In some respects, this could be considered a backwards breaking change as
this behavior has existed for a while and it's possible some clients have
made accommodations for this bug such that if we were to change the return
code to 204, it might break clients expecting to get a 201.

However, this could also be considered a bug fix.
I lean towards considering this a bug and would like to fix this.

Thoughts? Concerns?
We do plan to address this as we move resources to v3 of the cc api.

-Dieu
CF CAPI PM