Forcing 409 Dependency Constraint

Mechanism: When a resource has dependent child resources (foreign-key relationships, active sub-resources), many servers refuse deletion with 409 Conflict rather than cascading. The server must find the parent resource and inspect its dependency graph. A non-existing resource returns 404.

Isolated Variable: The request is a standard DELETE with no special headers or body. The only variable is whether the target resource exists and has active dependencies.

Oracle Signal: 409 (exists with dependencies) vs 404 (does not exist).

DELETE — Existing Resource with Dependencies

DELETE /api/categories/cat-5 HTTP/1.1
Host: target.com

HTTP/1.1 409 Conflict
Content-Type: application/json

{"error": "Conflict", "detail": "Cannot delete category with 12 active products"}

DELETE — Non-Existing Resource

DELETE /api/categories/cat-999 HTTP/1.1
Host: target.com

HTTP/1.1 404 Not Found
Content-Type: application/json

{"error": "Not Found"}

DELETE — Existing Resource without Dependencies

DELETE /api/categories/cat-7 HTTP/1.1
Host: target.com

HTTP/1.1 204 No Content

💡 Three-way signal: The dependency DELETE produces a three-way signal: 409 (exists with dependencies), 204/200 (existed and was deleted), or 404 (never existed). The 409 confirms existence non-destructively. The 204 also confirms existence but destroys the resource. Test against resource types likely to have children (parent categories, teams with members, projects with tasks).

💡 Error message as a dependency-graph oracle: The 409 body frequently enumerates blocking dependencies — count, type, and sometimes identifiers of child resources. "Cannot delete: 12 active products" reveals both the category's existence and its product count.

Mitigation: Return 404 for non-existent resources before evaluating dependency constraints. Avoid leaking dependency details in the 409 body.