Client-server architecture in Rest API - Time & Space Complexity

Time Complexity: Client-server architecture

O(n)

Understanding Time Complexity

When we use client-server architecture, the client sends requests and the server processes them. We want to understand how the time to handle these requests changes as more requests come in.

How does the server's work grow when many clients ask for data?

Scenario Under Consideration

Analyze the time complexity of the following code snippet.

// Server receives a list of user IDs
function getUserData(userIds) {
  let results = [];
  for (let id of userIds) {
    let data = database.queryUser(id); // fetch user data
    results.push(data);
  }
  return results;
}

This code fetches user data for each ID sent by the client, one by one.

Identify Repeating Operations

Identify the loops, recursion, array traversals that repeat.

• Primary operation: Loop over each user ID to query the database.
• How many times: Once for each user ID in the input list.

How Execution Grows With Input

As the number of user IDs increases, the server does more database queries, one per ID.

Input Size (n)	Approx. Operations
10	10 database queries
100	100 database queries
1000	1000 database queries

Pattern observation: The work grows directly with the number of user IDs; doubling the input doubles the work.

Final Time Complexity

Time Complexity: O(n)

This means the server's work grows in a straight line with the number of requests it handles.

Common Mistake

[X] Wrong: "The server handles all requests instantly, so time doesn't grow with more users."

[OK] Correct: Each request needs its own processing time, so more requests mean more total work and longer total time.

Interview Connect

Understanding how server work grows with requests helps you design better APIs and explain performance clearly in interviews. It shows you know how systems handle real-world loads.

Self-Check

"What if the server could fetch data for all user IDs in one database query? How would the time complexity change?"

Practice

1. In a client-server architecture, what is the main role of the client?

easy

A. To request data or services from the server

B. To store and manage data permanently

C. To control the network hardware

D. To provide power to the server

Solution

1. Step 1: Understand client role

   The client is the part of the system that asks for information or services.

2. Step 2: Differentiate from server role

   The server responds to client requests by sending data or services.

3. Final Answer:

   To request data or services from the server -> Option A

4. Quick Check:

   Client requests, server responds [OK]

Hint: Clients always ask; servers always answer [OK]

Common Mistakes:

• Confusing client with server
• Thinking client stores data permanently
• Assuming client controls network hardware

2. Which of the following is the correct way a client sends a request to a server in REST API?

easy

A. Using a SQL SELECT statement

B. Using an HTTP GET method

C. Using a FTP upload command

D. Using a local file read operation

Solution

1. Step 1: Identify REST API request methods

   REST APIs use HTTP methods like GET, POST, PUT, DELETE to communicate.

2. Step 2: Match method to client request

   GET is used by clients to request data from servers.

3. Final Answer:

   Using an HTTP GET method -> Option B

4. Quick Check:

   REST client requests use HTTP methods [OK]

Hint: REST clients use HTTP verbs like GET to ask [OK]

Common Mistakes:

• Confusing SQL with REST API
• Using FTP commands for REST requests
• Thinking local file reads send requests

3. What will the server respond with if a client sends a GET request to /users/123 and the user exists?

medium

A. A JSON object with user details

B. An error message saying 'User not found'

C. A redirect to the homepage

D. A blank page with no content

Solution

1. Step 1: Understand GET request to resource

   A GET request to /users/123 asks for user data with ID 123.

2. Step 2: Server response when user exists

   If user exists, server sends back user details, usually as JSON.

3. Final Answer:

   A JSON object with user details -> Option A

4. Quick Check:

   GET existing resource returns data [OK]

Hint: GET returns data if resource exists, else error [OK]

Common Mistakes:

• Assuming error if user exists
• Thinking GET causes redirect
• Expecting blank page on success

4. A client sends a POST request to create a new user, but the server responds with a 404 error. What is the most likely cause?

medium

A. The client sent too much data

B. The client used the wrong HTTP method

C. The server successfully created the user

D. The server URL endpoint is incorrect or missing

Solution

1. Step 1: Understand 404 error meaning

   404 means the requested URL or endpoint was not found on the server.

2. Step 2: Link error to cause

   If POST returns 404, likely the client sent request to wrong or missing URL.

3. Final Answer:

   The server URL endpoint is incorrect or missing -> Option D

4. Quick Check:

   404 means URL not found [OK]

Hint: 404 means wrong or missing URL endpoint [OK]

Common Mistakes:

• Confusing 404 with method error
• Assuming success on 404
• Thinking data size causes 404

5. You want to design a REST API where clients can update user info only if they provide a valid token. Which client-server architecture concept helps enforce this?

hard

A. Client directly modifying server database

B. Client caching data locally

C. Authentication and authorization on the server

D. Server sending data without checks

Solution

1. Step 1: Identify security need

   Allowing updates only with valid token means controlling access.

2. Step 2: Apply client-server security concept

   Authentication verifies identity; authorization controls permissions on server side.

3. Final Answer:

   Authentication and authorization on the server -> Option C

4. Quick Check:

   Access control = Authentication + Authorization [OK]

Hint: Use server-side auth to control client access [OK]

Common Mistakes:

• Thinking client caches control access
• Assuming server sends data without checks
• Believing client can modify database directly