PUT for full replacement in Rest API - Time & Space Complexity

Time Complexity: PUT for full replacement

O(n)

Understanding Time Complexity

When using PUT to fully replace a resource, it's important to know how the time to process the request changes as the resource size grows.

We want to understand how the server's work grows when replacing larger resources.

Scenario Under Consideration

Analyze the time complexity of the following REST API PUT request handler.

// PUT /items/{id}
function replaceItem(id, newItem) {
  // Validate newItem fields
  validate(newItem);
  // Overwrite existing item fully
  database[id] = newItem;
  // Save changes
  saveDatabase(database);
}
    

This code replaces an existing item fully with new data sent by the client.

Identify Repeating Operations

Look for operations that repeat or scale with input size.

• Primary operation: Validating and saving the entire new item data.
• How many times: The validation and saving steps process each field or data element once.

How Execution Grows With Input

As the size of the new item grows, the work to validate and save it grows too.

Input Size (n)	Approx. Operations
10 fields	About 10 validation and save steps
100 fields	About 100 validation and save steps
1000 fields	About 1000 validation and save steps

Pattern observation: The work grows directly with the number of fields in the item.

Final Time Complexity

Time Complexity: O(n)

This means the time to process the PUT request grows linearly with the size of the data being replaced.

Common Mistake

[X] Wrong: "PUT requests always take constant time because they just replace data."

[OK] Correct: The server must process every part of the new data, so larger data means more work and more time.

Interview Connect

Understanding how PUT requests scale helps you explain API performance and design choices clearly in real projects.

Self-Check

"What if the PUT request only updated some fields instead of replacing all? How would the time complexity change?"