Data integrity means that received data matches what was sent and has not been altered in transit. In API design, it also means keeping shared facts consistent rather than duplicating conflicting copies across resources. section 30.1.2 section 4.3.3
Apply integrity checks and resource boundaries deliberately:
- Reject requests whose content changed after sending; origin authentication alone does not prove request integrity. section 30.1.2
- Treat HTTP method, path, host, and selected body content as the request fingerprint when signing requests. section 30.6
- Keep shared facts in separate resources when in-lining would require unclear update rules or create stale duplicates. section 4.3.3
- Use 409 Conflict for duplicate membership additions and 412 Precondition Failed when removing a nonexistent membership. section 15.3.2
Books, authors, and signed requests
A library API can model an Author separately and let Book reference it, so changing an author’s name has one clear update location. If the name is copied into every Book, updates can diverge. Separately, a signed request can protect its method, path, host, and body fingerprint against transit tampering. section 4.3.3 section 30.6
Compare separate Book and Author resources with an in-line author representation to assess duplication and update-consistency risks. section 4.3.3
