Last-Modified and If-Modified-Since in Rest API - Time & Space Complexity

Time Complexity: Last-Modified and If-Modified-Since

O(n)

Understanding Time Complexity

When a server uses Last-Modified and If-Modified-Since headers, it decides if it needs to send data again.

We want to see how the time to handle requests changes as more requests come in.

Scenario Under Consideration

Analyze the time complexity of the following code snippet.

GET /resource HTTP/1.1
Host: example.com
If-Modified-Since: Wed, 21 Oct 2015 07:28:00 GMT

// Server side:
if (resource.lastModified <= request.headers['If-Modified-Since']) {
  return 304 Not Modified;
} else {
  return 200 OK with resource data;
}

This code checks if the resource has changed since the time the client last saw it, to decide if data should be sent.

Identify Repeating Operations

• Primary operation: Comparing the resource's last modified timestamp with the request header.
• How many times: Once per incoming request.

How Execution Grows With Input

Each request requires a simple timestamp comparison, which takes the same small amount of time regardless of resource size.

Input Size (number of requests)	Approx. Operations
10	10 timestamp comparisons
100	100 timestamp comparisons
1000	1000 timestamp comparisons

Pattern observation: The work grows directly with the number of requests, but each check is very fast and simple.

Final Time Complexity

Time Complexity: O(n)

This means the time to handle requests grows linearly with the number of requests, with each request taking a quick check.

Common Mistake

[X] Wrong: "The server must read the whole resource file every time to check if it changed."

[OK] Correct: The server only compares timestamps, which is a quick check and does not require reading the full resource each time.

Interview Connect

Understanding how simple checks like timestamp comparisons scale helps you explain efficient server responses and caching in real projects.

Self-Check

"What if the server had to read the entire resource content to compare it each time? How would the time complexity change?"

Practice

1. What is the main purpose of the Last-Modified header in a REST API response?

easy

A. To tell the client when the resource was last changed

B. To tell the client the size of the resource

C. To tell the client the type of the resource

D. To tell the client the server's current time

Solution

1. Step 1: Understand the role of Last-Modified header

   The Last-Modified header indicates the date and time when the resource was last changed on the server.

2. Step 2: Compare options with the header's purpose

   Only To tell the client when the resource was last changed correctly describes this purpose. Other options describe unrelated information.

3. Final Answer:

   To tell the client when the resource was last changed -> Option A

4. Quick Check:

   Last-Modified = resource last change time [OK]

Hint: Last-Modified shows last change date of resource [OK]

Common Mistakes:

• Confusing Last-Modified with Content-Length
• Thinking it shows server current time
• Mixing it up with Content-Type header

2. Which of the following is the correct syntax to send an If-Modified-Since header in an HTTP request?

easy

A. If-Modified-Since: 2023-01-01T12:00:00Z

B. If-Modified-Since = "2023-01-01 12:00:00"

C. If-Modified-Since -> 01/01/2023 12:00

D. If-Modified-Since: Sun, 01 Jan 2023 12:00:00 GMT

Solution

1. Step 1: Recall HTTP header date format

   HTTP headers use the RFC 1123 date format like Sun, 01 Jan 2023 12:00:00 GMT for date/time values.

2. Step 2: Match options to correct format

   If-Modified-Since: Sun, 01 Jan 2023 12:00:00 GMT matches the correct header syntax and date format. Other options use invalid syntax or date formats.

3. Final Answer:

   If-Modified-Since: Sun, 01 Jan 2023 12:00:00 GMT -> Option D

4. Quick Check:

   If-Modified-Since uses RFC 1123 date format [OK]

Hint: Use RFC 1123 date format for If-Modified-Since header [OK]

Common Mistakes:

• Using ISO 8601 instead of RFC 1123 format
• Using '=' instead of ':' in header
• Using arrow '->' instead of colon

3. Given the server responds with header Last-Modified: Wed, 10 May 2023 10:00:00 GMT, what will the server respond if the client sends If-Modified-Since: Wed, 10 May 2023 09:00:00 GMT?

medium

A. HTTP 400 Bad Request

B. HTTP 304 Not Modified

C. HTTP 200 OK with resource data

D. HTTP 500 Internal Server Error

Solution

1. Step 1: Compare If-Modified-Since with Last-Modified

   The client's If-Modified-Since date is earlier (09:00) than the server's Last-Modified date (10:00).

2. Step 2: Determine server response based on dates

   Since the resource was modified after the client's date, the server sends full data with HTTP 200 OK.

3. Final Answer:

   HTTP 200 OK with resource data -> Option C

4. Quick Check:

   If-Modified-Since < Last-Modified -> 200 OK [OK]

Hint: If client date before last change, server sends full data [OK]

Common Mistakes:

• Thinking server sends 304 when resource changed after client date
• Confusing 400 Bad Request with conditional headers
• Assuming server error on date mismatch

4. A client sends If-Modified-Since: Tue, 09 May 2023 10:00:00 GMT but the server always responds with HTTP 200 OK and full data, ignoring the header. What is the likely error in server handling?

medium

A. Server does not check If-Modified-Since header before sending data

B. Server sends wrong Last-Modified date format

C. Client sent If-Modified-Since header incorrectly

D. Server is missing Content-Type header

Solution

1. Step 1: Understand expected server behavior

   The server should compare If-Modified-Since with resource's Last-Modified and respond 304 if not changed.

2. Step 2: Identify why server always sends 200 OK

   If server ignores the header and always sends full data, it likely does not check the If-Modified-Since header properly.

3. Final Answer:

   Server does not check If-Modified-Since header before sending data -> Option A

4. Quick Check:

   Ignoring If-Modified-Since means always 200 OK [OK]

Hint: Server must check If-Modified-Since to send 304 [OK]

Common Mistakes:

• Blaming client for server ignoring header
• Thinking wrong Last-Modified format causes 200 OK
• Confusing Content-Type header with caching headers

5. You want to optimize your REST API to reduce bandwidth by using Last-Modified and If-Modified-Since. Which approach correctly implements this optimization?

hard

A. Ignore If-Modified-Since and always send full resource with Last-Modified

B. Send Last-Modified header with resource date; on request, check If-Modified-Since and respond 304 if unchanged

C. Send If-Modified-Since header from server to client to indicate last change

D. Use Last-Modified header only on POST requests

Solution

1. Step 1: Understand how Last-Modified and If-Modified-Since work together

   The server sends Last-Modified header with the resource's last change date. The client sends If-Modified-Since header on next request to ask if resource changed since that date.

2. Step 2: Implement correct server logic for optimization

   The server compares If-Modified-Since with resource's last modified date and returns HTTP 304 Not Modified if unchanged, saving bandwidth.

3. Final Answer:

   Send Last-Modified header with resource date; on request, check If-Modified-Since and respond 304 if unchanged -> Option B

4. Quick Check:

   Send Last-Modified + check If-Modified-Since -> 304 optimization [OK]

Hint: Send Last-Modified; respond 304 if If-Modified-Since matches [OK]

Common Mistakes:

• Sending If-Modified-Since from server instead of client
• Ignoring If-Modified-Since header in server logic
• Using Last-Modified only on POST requests