Which description best defines idempotent endpoints?

• A. Endpoints should never be retried.
• B. Endpoints may change state on repeated requests.
• C. Endpoints require manual retries.
• D. Idempotent endpoints can be retried multiple times with the same result.

Answer: (D)

Idempotence means performing the same operation multiple times yields the same result as doing it once. An idempotent endpoint can be retried safely, even after a timeout or transient failure, without changing the outcome. This is why describing such endpoints as being retried multiple times with the same result fits perfectly: repeated requests won’t accumulate extra effects or data, just the same final state.

For example, fetch actions (GET) don’t change server state, and updates that set a resource to a fixed value (PUT) or delete a resource (DELETE) ultimately produce the same result if you repeat them. That reliability under repetition is what idempotence is about.

The other statements don’t capture this behavior. Saying endpoints should never be retried ignores real-world networking where retries are common. If repeated requests can change state, the operation isn’t idempotent. Requiring manual retries isn’t the defining trait of idempotence.