Forcing 409 Uniqueness Constraint

Mechanism: Per RFC 9110 §15.5.10, a server returns 409 Conflict when the request conflicts with the current state. Attempting to create a resource with a field value that must be unique but already exists triggers a collision check — the server must resolve the target collection and query existing records.

Isolated Variable: The request is completely valid. Only the value of a unique field is set to one that already exists in the system.

Oracle Signal: 409 (parent resource/collection exists, uniqueness check ran) vs 404 (parent resource does not exist).

POST — Existing Parent Resource (Duplicate Member)

POST /api/teams/team-abc/members HTTP/1.1
Host: target.com
Content-Type: application/json
Content-Length: 36

{"email": "alice@example.com"}

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

{"error": "Conflict", "detail": "Member with email alice@example.com already exists"}

POST — Non-Existing Parent Resource

POST /api/teams/team-zzz/members HTTP/1.1
Host: target.com
Content-Type: application/json
Content-Length: 36

{"email": "alice@example.com"}

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

{"error": "Not Found"}

💡 Pre-requisite knowledge: This technique requires you to know (or guess) a field value that already exists in the system. If you don't have a confirmed duplicate value, the server will accept the payload and return 2xx, which also confirms existence but at the cost of actually mutating state.

Mitigation: Check resource existence and return 404 before running uniqueness validation. Alternatively, return a generic 400 or 422 for all validation failures regardless of resource existence.