412 Precondition Failed

Category: Status Codes & Responses

Description

Operations that support conditional requests (If-Match, If-Unmodified-Since headers) should define a 412 Precondition Failed response.

What It Checks

This rule checks PUT, PATCH, and DELETE operations that define conditional header parameters and verifies they include a 412 response definition.

• Checks for conditional header parameters: If-Match, If-Unmodified-Since, If-None-Match
• Only examines operations where these headers are explicitly defined
• Verifies 412 response is documented

Why It Matters

Conditional requests enable optimistic concurrency control. Documenting 412 responses:

• Concurrency Handling: Clients know when their precondition failed
• Data Integrity: Prevents lost updates in concurrent environments
• Proper Error Handling: Clients can retry with fresh data
• RESTful Design: Follows HTTP conditional request semantics

Examples

Good

paths:
  /users/{id}:
    put:
      operationId: updateUser
      parameters:
        - name: id
          in: path
          required: true
        - name: If-Match
          in: header
          description: ETag value for conditional update
      responses:
        '200':
          description: User updated
        '412':
          description: Precondition Failed - ETag mismatch

Bad

paths:
  /users/{id}:
    put:
      operationId: updateUser
      parameters:
        - name: id
          in: path
          required: true
        - name: If-Match
          in: header
          description: ETag value for conditional update
      responses:
        '200':
          description: User updated
        # Missing 412 response

Exceptions

• Operations without conditional header parameters
• GET operations (typically use 304 Not Modified instead)

Configuration

This rule has no configuration options. It is either enabled or disabled.

Related Rules

• Rule 59: ETag Headers - ETag header usage
• Rule 60: Conditional PUT - Conditional update support