Query parameter versioning in Rest API - Time & Space Complexity

Time Complexity: Query parameter versioning

O(n)

Understanding Time Complexity

When using query parameter versioning in REST APIs, it's important to understand how the time to handle requests changes as the number of versions grows.

We want to know how the server's work increases when it checks the version from the query parameter.

Scenario Under Consideration

Analyze the time complexity of the following code snippet.

// Example of query parameter versioning
app.get('/api/resource', (req, res) => {
  const version = req.query.v;
  if (version === '1') {
    // handle version 1
  } else if (version === '2') {
    // handle version 2
  } else {
    // default handler
  }
  res.send('response');
});
    

This code checks the version number from the query parameter and chooses the matching handler.

Identify Repeating Operations

Identify the loops, recursion, array traversals that repeat.

• Primary operation: Checking the version value against each supported version in sequence.
• How many times: Once per request, but the number of checks grows with the number of versions.

How Execution Grows With Input

As the number of supported versions increases, the server checks more conditions to find the right handler.

Number of Versions (n)	Approx. Checks
2	2 checks
10	10 checks
100	100 checks

Pattern observation: The number of checks grows directly with the number of versions.

Final Time Complexity

Time Complexity: O(n)

This means the time to find the correct version handler grows linearly as more versions are added.

Common Mistake

[X] Wrong: "Checking the version is always constant time because it's just one query parameter."

[OK] Correct: When many versions exist, the server must check each version condition one by one, so time grows with the number of versions.

Interview Connect

Understanding how version checks scale helps you design APIs that stay fast as they grow. This skill shows you can think about performance beyond just making code work.

Self-Check

"What if we replaced the if-else checks with a direct lookup in a dictionary mapping versions to handlers? How would the time complexity change?"

Practice

1. What is the main purpose of using query parameter versioning in REST APIs?

easy

A. To change the main URL path for each API version

B. To allow clients to specify which API version they want using a query string

C. To hide the API version from clients

D. To force all clients to use the latest API version only

Solution

1. Step 1: Understand query parameter versioning concept

   Query parameter versioning lets clients add a version number in the URL query string, like ?version=1.

2. Step 2: Identify the purpose of this method

   This allows clients to choose which API version to use without changing the main URL path.

3. Final Answer:

   To allow clients to specify which API version they want using a query string -> Option B

4. Quick Check:

   Query parameter versioning = client selects version [OK]

Hint: Version in query string means client chooses API version [OK]

Common Mistakes:

• Thinking versioning changes the main URL path
• Assuming versioning hides API versions
• Believing all clients must use latest version only

2. Which of the following is the correct way to request version 2 of an API using query parameter versioning?

easy

A. GET /api/resource/version=2

B. GET /api/version/2/resource

C. GET /api/resource?version=2

D. GET /api/resource#version=2

Solution

1. Step 1: Recall query parameter syntax in URLs

   Query parameters come after a question mark ? and use key=value pairs, e.g., ?version=2.

2. Step 2: Match the correct syntax for versioning

   The correct way to specify version 2 is by adding ?version=2 after the resource path.

3. Final Answer:

   GET /api/resource?version=2 -> Option C

4. Quick Check:

   Query param syntax = ?key=value [OK]

Hint: Query parameters start with ? and use key=value [OK]

Common Mistakes:

• Using slashes instead of query parameters
• Using # instead of ? for query parameters
• Placing version inside the URL path incorrectly

3. Given this API endpoint code snippet handling versioning:

def get_data(request):
    version = request.GET.get('version', '1')
    if version == '1':
        return 'Data from v1'
    elif version == '2':
        return 'Data from v2'
    else:
        return 'Unknown version'

What will be the output if the client calls /api/data?version=2?

medium

A. "Data from v2"

B. "Unknown version"

C. "Data from v1"

D. Error: version parameter missing

Solution

1. Step 1: Extract version from query parameters

   The code gets the version from the query string. If missing, it defaults to '1'. Here, version='2'.

2. Step 2: Check version conditions

   Since version is '2', the code returns 'Data from v2'.

3. Final Answer:

   "Data from v2" -> Option A

4. Quick Check:

   version=2 returns v2 data [OK]

Hint: Check query param value matches version condition [OK]

Common Mistakes:

• Assuming default version is always used
• Confusing string and integer comparison
• Expecting error when version is provided

4. Consider this code snippet for versioning:

def api_handler(request):
    version = request.GET['version']
    if version == '1':
        return 'Version 1'
    else:
        return 'Other version'

What error will occur if the client calls /api/data without a version parameter?

medium

A. KeyError because 'version' key is missing

B. SyntaxError in code

C. Returns 'Version 1' by default

D. Returns 'Other version'

Solution

1. Step 1: Understand how version is accessed

   The code uses request.GET['version'] which raises KeyError if 'version' is missing.

2. Step 2: Analyze call without version parameter

   Calling without ?version=... means 'version' key is missing, causing KeyError.

3. Final Answer:

   KeyError because 'version' key is missing -> Option A

4. Quick Check:

   Missing key access causes KeyError [OK]

Hint: Access query keys safely to avoid KeyError [OK]

Common Mistakes:

• Assuming default version is used automatically
• Expecting no error when parameter is missing
• Confusing KeyError with SyntaxError

5. You want to support versions 1 and 2 of your API using query parameter versioning. Version 1 returns a list of users as strings, and version 2 returns a list of user objects with 'name' and 'id'. Which approach correctly handles this in a single endpoint?

hard

A. Return an error if version parameter is missing or unknown

B. Change the URL path to /v1/users and /v2/users instead of query parameters

C. Ignore the version parameter and always return the latest format

D. Use ?version=1 to return ['Alice', 'Bob'], and ?version=2 to return [{'name':'Alice','id':1},{'name':'Bob','id':2}]

Solution

1. Step 1: Understand query parameter versioning usage

   Clients specify version using ?version=1 or ?version=2 in the same URL.

2. Step 2: Return different data formats based on version

   Return simple list of strings for version 1, and detailed objects for version 2, matching client request.

3. Final Answer:

   Use ?version=1 to return ['Alice', 'Bob'], and ?version=2 to return [{'name':'Alice','id':1},{'name':'Bob','id':2}] -> Option D

4. Quick Check:

   Query param version controls response format [OK]

Hint: Return data format based on version query param [OK]

Common Mistakes:

• Changing URL path instead of using query parameters
• Ignoring version parameter and mixing formats
• Returning errors unnecessarily for missing versions