Request id

As explained in API Design Patterns

A request identifier is a value associated with an API request so that the request can be distinguished, tracked, and recognized across repeated attempts.

A request ID is a client-chosen value attached to an API request so the service can recognize repeated attempts. It lets the server safely retry non-idempotent operations when the client cannot tell whether the first attempt succeeded. section 26.0 section 26.6

The server treats the ID as a temporary, single-use counterpart to a resource identifier. If the ID is absent, the request proceeds normally; if it is invalid, the server rejects it, such as with 400 Bad Request. Clients should generate random values that follow the API’s identifier format rather than deriving IDs from request bodies. section 26.3.1

Implement request-ID deduplication with these rules:

• Check the cache before processing a request. On a miss, execute the operation, store the complete response, and return it. section 26.3.2
• On a cache hit, return the originally cached response rather than an error or a newly calculated result. section 26.2 section 26.3.3
• Store a fingerprint of the request body with the response. Return the cached result only when the repeated request matches; otherwise return 409 Conflict. section 26.3.4
• Apply the mechanism selectively because it adds method complexity, cache storage, and expiration or invalidation decisions; require it for especially sensitive operations when appropriate. section 26.4 section 26.6

Retrying a create request

A client sends CreateChatRoom with requestId `r-7f...`, but the response is lost. It retries with the same ID. The server finds the stored response and returns the original chat-room identifier without creating another room. If the retry uses that ID with a different request body, the server reports 409 Conflict instead of returning an unrelated cached response. section 26.2 section 26.3.4

Figure 26.3 Overview of the sequence of events for deduplicating requests

Use the sequence diagram to trace the cache check, first execution, response storage, and duplicate response. section 26.2

How API Design Patterns covers it

How deep it goes

Defines client generation, validation, caching, fingerprints, collisions, and consistency trade-offs, but leaves cache operations illustrative.

Examples

Uses ChatRoom creation and updates, lost responses, repeated attempts, cached results, and conflicting request bodies.

What it assumes

Assumes API request and response concepts, while teaching request identifiers and deduplication from their basic purpose.

What you can do after

Build it from scratch by adding client IDs, response caching, body fingerprints, validation, and collision errors to selected API methods.

How it connects

Connects request deduplication with idempotence, response caching, resource identifiers, consistency, hashing, and HTTP errors.

liveBookmanning.com

Read API Design Patterns on liveBook Get the book at manning.com

Related concepts

• retryused by · A retry is a subsequent attempt to perform an operation after an earlier attempt fails or does not complete successfully.
• clientproduced by · A client is a person, organization, device, or software component that receives or uses a product, service, resource, or functionality provided by another entity.
• response dedupinguses · Response deduping is the technique of handling repeated requests for the same logical operation as one operation whose result or effects are shared.
• cachingused by · Caching is the practice of storing reusable data or computation results so later access can avoid repeating retrieval or computation.
• hash collisionproduces · A hash collision occurs when distinct inputs to a hash function produce the same hash value or map to the same hash-table location.

This explainer was generated by Manning's knowledge graph from the text of API Design Patterns. The section links point to the parts of the book it draws on.