Forcing 409 Uniqueness Constraint

Mechanism: Per RFC 9110 §15.5.10, attempting to update a resource with a field value that must be unique but already exists in another record triggers 409. The server must resolve the target resource, then query existing records for the collision.

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

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

PUT — Existing Resource (Duplicate Email on Update)

PUT /api/users/1001 HTTP/1.1
Host: target.com
Content-Type: application/json
Content-Length: 52

{"name": "Test", "email": "taken@example.com"}

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

{"error": "Conflict", "detail": "Email already in use by another account"}

PUT — Non-Existing Resource (Duplicate Email on Update)

PUT /api/users/9999 HTTP/1.1
Host: target.com
Content-Type: application/json
Content-Length: 52

{"name": "Test", "email": "taken@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. Without a confirmed duplicate value, the server will accept the payload and return 2xx, mutating state.

Mitigation: Check resource existence and return 404 before running uniqueness validation.