A validation request checks whether an API operation would succeed without applying its changes. It gives users a safer preview before executing dangerous or expensive work. section 19.3 section 27.4
Design validation requests around these rules:
- Expose an explicit Boolean field such as validateOnly, defaulting to false so ordinary requests still perform their work. section 27.2 section 27.3
- Validate as many aspects as possible, including authorization, resource existence, referential integrity, and parameter correctness. section 27.2 section 27.3
- Return the same errors a real execution would return, while making successful responses representative without requiring unavailable values such as server-generated identifiers. section 27.2 section 27.3
- Preserve safety, idempotence, and side-effect freedom; skip external checks that would require real-world effects, and use safer substitutes when possible. section 27.3.1 section 27.6
Previewing a criteria-based purge
Send a purge request with its filter and force unset or false. The response supplies purgeSample identifiers and an estimated purgeCount, allowing the caller to verify the filter. If the result is correct, resend the same request with force set to true; the execution response reports the number of resources deleted. section 19.3
Use the interaction pattern to compare the validation request with its subsequent destructive execution. section 19.3
