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

John Feminella

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.