Referential integrity keeps references valid and connected to the intended resources. APIs must define what happens when a referenced resource is deleted, moved, copied, or soft-deleted; otherwise clients face inconsistent behavior and dangling pointers. section 13.0 section 25.3.6
Choose an explicit deletion policy for resources that other resources reference:
- Cascade deletes every resource pointing to the deleted resource, but can trigger an avalanche of deletions. section 14.3.6
- Restrict prevents deletion while references exist; an API can return HTTP 412 Precondition Failed. section 14.3.6
- Set null clears all pointers, but can create a stampede of writes across large numbers of resources. section 14.3.6
- Do nothing permits deletion and leaves dangling references for consumers to handle. section 14.3.6
Association resource deletion
Suppose MessageReviewReport contains messageId pointing to Message. Deleting that Message should generally either be rejected while the report exists or proceed while leaving the report's pointer invalid. Cascading or nulling references may produce unbounded deletion or update workloads. section 14.3.6
Moving resources is harder than deleting them: every resource referring to the moved target, including descendants moved indirectly with a parent, may require updates. This complexity makes renaming or relocating resources undesirable. Soft deletion should preserve the existing reference policy rather than silently changing it. section 17.3.3 section 25.3.6
Table 14.3 Summary of referential integrity behavior (view table figure)
Compare cascade, restrict, set-null, and do-nothing policies before choosing deletion behavior. section 14.3.6
