HTTP 412 ā Precondition Failed
HTTP 412 answers conditional requests whose If-Match or If-Unmodified-Since test failed: the resource changed underneath the client, so the server refuses to apply the operation on stale assumptions.
When 412 shows up
- Optimistic-edit flows where another writer got there first.
- Conditional deletes guarded by an ETag the client last saw earlier.
Mocking a 412 response
A response with this status can be faked end to end with a local mock rule ā no backend changes needed. The configuration below mirrors the rule fields the ApiSimul editor uses (method, path, status, delay in milliseconds, response body):
{
"method": "GET",
"path": "/api/docs/{{param.id}}",
"status": 412,
"delay": 180,
"enabled": true,
"body": {
"error": "stale_version",
"currentEtag": "abc123"
}
}Dynamic placeholders such as {{random.name}}, {{string.uuid}} or {{number.int 1 100}} can appear inside the body to vary each response, which keeps client-side list rendering and retry logic honest during development.
Frequently asked questions
What does HTTP 412 mean?
One or more request preconditions evaluated false against the current resource state. The client should refresh and rebuild its request.
How can I test a 412 response without a real backend?
Define a mock rule with the method and path your client requests and set the status to 412. The example configuration above returns this response after the listed delay, so the client exercises its 412 handling exactly as it would against a live server.
Related status codes
Need the response in your own project? Spin up rules for any status with the ApiSimul mock server, or browse every status code page.