Re: considering changing response code on deletes on v2 end points

Dieu Cao <dcao@...>

On further review, there's a mix of return codes currently returned on
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)>

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)
t · @jxxf
On Oct 14, 2015 21:09, "Dieu Cao" <dcao(a)> wrote:

Hi All,

Most of cloud controller api's v2 end points currently return a 201 on
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.


Join { to automatically receive all group messages.