Idempotency vs safety на собеседовании системного аналитика

Definitions

Safe. Не modifies state. GET, HEAD, OPTIONS.

Idempotent. Multiple calls — same result as one. GET, PUT, DELETE.

Cacheable. Can be cached. GET, HEAD typically.

Safe → idempotent (но не vice versa).

HTTP methods table

Why matters

Browsers / proxies / clients assume GET safe. Action-on-GET — anti-pattern.

Bad: GET /delete-user?id=42  ← deletes!
Good: DELETE /users/42

Crawlers / prefetch trigger random GETs — should be safe.

Retries. Idempotent ops can retry без worry. POST may create duplicate — retry hazardous.

Caveats

PUT idempotent. Multiple PUT /users/42 {name: "Alice"} — same result. But race conditions могут create issues.

DELETE idempotent. First call returns 200. Second 404. Different responses, но same final state — semantically idempotent.

POST не idempotent BY DEFAULT. Make idempotent через Idempotency-Key header — server dedupes.

PATCH depends. PATCH {amount: 100} — idempotent (set value). PATCH {amount: +10} — не (each call adds).

Связанные темы

• HTTP методы и коды для SA
• Идемпотентность API для SA
• Idempotency key для SA
• REST API для SA
• Подготовка к собесу системного аналитика

FAQ

Это официальная информация?

Нет. Статья основана на RFC 9110 (HTTP Semantics).

Тренируйте системный анализ — откройте тренажёр с 1500+ вопросами для собесов.