What technique helps prevent duplicate records when clients retry requests in an address API?

What technique helps prevent duplicate records when clients retry requests in an address API?

• A. Idempotent design using PUT/DELETE
• B. Random IDs
• C. Logging
• D. No practice

Answer: (A)

Idempotent design keeps retries from creating duplicates. When a client retries a request because of a timeout or network hiccup, you want the repeated call to have the same effect as the first one. Using idempotent methods like PUT (and DELETE) achieves that in an address API by operating on a stable resource identifier. For example, by routing updates or creates through a PUT to a fixed path such as /addresses/{addressId}, repeating the same PUT doesn’t create a new address each time; it upserts or replaces the existing one, so only one record emerges. Similarly, DELETE is idempotent, so retrying a delete after the resource is already removed doesn’t re-create anything or cause extra records. Random IDs could lead to duplicates on retries, logging helps track what happened but doesn’t prevent duplicates, and no practice offers no protection. Using idempotent design with PUT/DELETE provides a reliable way to handle retries gracefully.