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