ETag for conditional requests in Rest API - Step-by-Step Execution

Concept Flow - ETag for conditional requests

Client sends GET request

↓

Server checks resource state

↓

Server generates ETag for resource

↓

Server sends response with ETag header

↓

Client stores ETag

↓

Client sends conditional GET with If-None-Match: ETag

↓

Server compares ETag with current resource

↓

ETag matches

↓

Send 304 Not Modified

The client requests a resource, server sends it with an ETag. Later, client asks conditionally using that ETag. Server replies 304 if unchanged or 200 with new data if changed.

Execution Sample

Rest API

GET /resource HTTP/1.1
Host: example.com

--- Server Response ---
HTTP/1.1 200 OK
ETag: "abc123"
Content: {"data": "value"}

--- Conditional Request ---
GET /resource HTTP/1.1
If-None-Match: "abc123"
Host: example.com

Client first gets resource with ETag, then sends conditional request with If-None-Match header.

Execution Table

Step	Request Type	ETag Sent by Client	Server ETag	ETag Match?	Server Response
1	Initial GET	None	"abc123"	N/A	200 OK with resource and ETag "abc123"
2	Conditional GET	"abc123"	"abc123"	Yes	304 Not Modified, no body
3	Conditional GET	"abc123"	"def456"	No	200 OK with new resource and ETag "def456"

💡 Execution stops after server responds based on ETag match.

Variable Tracker

Variable	Start	After Step 1	After Step 2	After Step 3
Client ETag	None	"abc123"	"abc123"	"abc123" or updated to "def456" if resource changed
Server Resource State	"value"	"value"	"value"	"new value" if changed
Server ETag	N/A	"abc123"	"abc123"	"def456"

Key Moments - 3 Insights

Why does the server send 304 Not Modified instead of 200 OK?

Because the client's If-None-Match ETag matches the server's current ETag (see execution_table row 2), meaning the resource has not changed.

What happens if the resource changes on the server?

The server generates a new ETag (see execution_table row 3), so the ETag does not match the client's. The server sends 200 OK with the updated resource and new ETag.

Why does the client send the ETag in the If-None-Match header?

To ask the server if the resource has changed since last fetch, enabling efficient caching and saving bandwidth if unchanged.

Visual Quiz - 3 Questions

Look at the execution_table, what response does the server send at step 2?

A 200 OK with new resource

B 304 Not Modified

C 404 Not Found

D 500 Internal Server Error

💡 Hint

Check the 'Server Response' column in execution_table row 2.

At which step does the server detect that the resource has changed?

A Step 1

B Step 2

C Step 3

D None of the above

💡 Hint

Look at the 'ETag Match?' column and 'Server Response' in execution_table.

If the client sends a different ETag in If-None-Match at step 2, what changes in the execution_table?

A Server responds 304 Not Modified

B Server responds 200 OK with new resource

C Client ETag becomes None

D Server ETag becomes None

💡 Hint

Refer to execution_table row 3 where ETag does not match.

Concept Snapshot

ETag is a unique identifier for a resource version.
Client stores ETag from server response.
Client sends If-None-Match with ETag to check freshness.
Server compares ETag; if match, sends 304 Not Modified.
If no match, sends 200 OK with new resource and ETag.
This saves bandwidth by avoiding sending unchanged data.

Full Transcript

This visual execution shows how ETag works for conditional requests in REST APIs. First, the client requests a resource. The server responds with the resource and an ETag header, a unique tag representing the resource version. The client saves this ETag. Later, the client sends a conditional GET request with the If-None-Match header containing the saved ETag. The server compares this ETag with the current resource's ETag. If they match, the server replies with 304 Not Modified, meaning the resource has not changed, so the client can use its cached copy. If they differ, the server sends 200 OK with the updated resource and a new ETag. This process helps reduce data transfer and improves efficiency by avoiding sending unchanged data.

Practice

1.

What is the main purpose of an ETag in REST APIs?

easy

A. To help clients check if the resource has changed since last fetch

B. To encrypt the data sent from server to client

C. To authenticate the client making the request

D. To specify the content type of the response

Solution

1. Step 1: Understand ETag role in REST

   ETags are unique identifiers for resource versions, used to detect changes.

2. Step 2: Match purpose with options

   Only To help clients check if the resource has changed since last fetch describes checking if resource changed, which is the ETag's purpose.

3. Final Answer:

   To help clients check if the resource has changed since last fetch -> Option A

4. Quick Check:

   ETag purpose = freshness check [OK]

Hint: ETags track changes, not encrypt or authenticate [OK]

Common Mistakes:

• Confusing ETag with authentication tokens
• Thinking ETag encrypts data
• Assuming ETag sets content type

2.

Which HTTP header should a client send to make a conditional GET request using an ETag?

easy

A. If-Modified-Since

B. If-None-Match

C. ETag

D. Cache-Control

Solution

1. Step 1: Identify client header for ETag conditional requests

   The client sends If-None-Match header with the ETag value to check freshness.

2. Step 2: Compare options

   If-Modified-Since uses dates, ETag is a response header, Cache-Control controls caching rules. Only If-None-Match fits.

3. Final Answer:

   If-None-Match -> Option B

4. Quick Check:

   Client uses If-None-Match for ETag check [OK]

Hint: Client sends If-None-Match with ETag to check freshness [OK]

Common Mistakes:

• Using ETag header in request instead of response
• Confusing If-Modified-Since with ETag usage
• Sending Cache-Control instead of conditional header

3.

Given this HTTP interaction:
GET /resource HTTP/1.1
Host: example.com
If-None-Match: "abc123"
Server responds:
HTTP/1.1 304 Not Modified
What does this response mean?

medium

A. The resource has changed and new data is sent

B. The server encountered an error

C. The resource has not changed; client should use cached data

D. The request is unauthorized

Solution

1. Step 1: Understand 304 Not Modified status

   304 means resource is unchanged since client's ETag, so no new data sent.

2. Step 2: Match meaning with options

   The resource has not changed; client should use cached data correctly states client should use cached data because resource is unchanged.

3. Final Answer:

   The resource has not changed; client should use cached data -> Option C

4. Quick Check:

   304 = Not Modified, use cache [OK]

Hint: 304 means no change; use cached copy [OK]

Common Mistakes:

• Thinking 304 means new data sent
• Confusing 304 with error or unauthorized status
• Ignoring ETag and caching role

4.

Consider this server code snippet handling ETags:

etag = generate_etag(resource)
if request.headers.get('If-None-Match') == etag:
    return Response(status=304)
else:
    return Response(data=resource, headers={'ETag': etag})

What is a potential bug in this code?

medium

A. It compares ETag strings without quotes, causing mismatch

B. It returns 304 even if ETag does not match

C. It does not handle If-Modified-Since header

D. It always returns data ignoring conditional requests

Solution

1. Step 1: Analyze ETag comparison

   ETags in headers often include quotes, so direct string equality may fail if quotes differ.

2. Step 2: Identify mismatch cause

   If client sends "abc123" but server etag is abc123 without quotes, comparison fails incorrectly.

3. Final Answer:

   It compares ETag strings without quotes, causing mismatch -> Option A

4. Quick Check:

   ETag quotes matter in comparison [OK]

Hint: ETag strings must match exactly including quotes [OK]

Common Mistakes:

• Ignoring quotes around ETag values
• Assuming If-Modified-Since is required for ETag logic
• Returning 304 without checking ETag

5.

You want to optimize your REST API to reduce bandwidth by using ETags. Which approach correctly implements conditional GET requests with ETags?

1. Server generates ETag for resource.
2. Server sends ETag in response header.
3. Client stores ETag.
4. Client sends GET with If-None-Match header.
5. Server compares ETag and returns 304 if unchanged.
6. Otherwise, server sends new data with new ETag.

Which step is missing or incorrect?

hard

A. Step 6: Server should always send 200 status even if unchanged

B. Step 4: Client should send If-Modified-Since instead of If-None-Match

C. Step 3: Client should not store ETag

D. Step 5: Server must compare ETag including quotes exactly

Solution

1. Step 1: Review each step for correctness

   Steps 1-4 are correct standard flow for ETag conditional requests.

2. Step 2: Identify subtle issue in step 5

   Server must compare ETag values exactly, including quotes, or else conditional check fails.

3. Step 3: Confirm other options are incorrect

   Client should store ETag (step 3), If-None-Match is correct header (step 4), and 304 status is correct for unchanged (step 6).

4. Final Answer:

   Step 5: Server must compare ETag including quotes exactly -> Option D

5. Quick Check:

   Exact ETag match including quotes is required [OK]

Hint: ETag comparison must be exact including quotes [OK]

Common Mistakes:

• Ignoring quotes in ETag comparison
• Using wrong conditional header
• Sending 200 instead of 304 for unchanged resource