miji.beIdempotency is the property that executing an operation once or multiple times yields the same outcome. In mathematics it is expressed as f(f(x)) = f(x). In web API design, idempotency ensures that retrying a request after a network failure or timeout does not cause unintended side effects such as duplicate records or double charges.
HTTP methods have defined idempotency characteristics. GET, PUT, and DELETE are idempotent, while POST is non-idempotent (each call may create a new resource). Idempotent here means that the effect on the server of sending the same request several times is the same as sending it once. The responses need not be identical: a first DELETE typically returns 200, and later ones often return 404 because the target is already gone, which does not break idempotency.
For a URL shortening API, idempotency is a core design question. If the same long URL is submitted twice, should two different short URLs be created, or should the same short URL be returned both times? An idempotent design returns the same short URL for the same input, preventing duplicates when a client retries after a network error.
A common implementation technique is the idempotency key. The client attaches a unique key (typically a UUID) to each request. The server caches the result for that key. If the same key appears again, the server returns the cached result without re-executing the operation. Stripe's payment API is a well-known example of this pattern.
In URL shortening services, idempotency is often combined with URL normalization. The input URL is normalized, a hash is computed, and the same hash always maps to the same short code. This also means that "https://example.com/page" and "https://example.com/page/" resolve to the same short URL.