Media type versioning in Rest API - Time & Space Complexity
When using media type versioning in REST APIs, it's important to understand how the server handles requests with different versions.
We want to know how the processing time changes as the number of versions or requests grows.
Analyze the time complexity of the following code snippet.
GET /api/resource HTTP/1.1
Accept: application/vnd.example.v1+json
// Server checks the Accept header
switch (version) {
case 'v1': return dataV1;
case 'v2': return dataV2;
default: return error;
}
This code checks the version requested in the Accept header and returns the matching data format.
Identify the loops, recursion, array traversals that repeat.
- Primary operation: Checking the version string against known versions.
- How many times: Once per request, with a small fixed number of versions to check.
As the number of requests grows, the server checks the version once per request.
| Input Size (n) | Approx. Operations |
|---|---|
| 10 requests | 10 version checks |
| 100 requests | 100 version checks |
| 1000 requests | 1000 version checks |
Pattern observation: The work grows directly with the number of requests, but each check is simple and fixed.
Time Complexity: O(n)
This means the time to handle requests grows linearly with the number of requests.
[X] Wrong: "Checking the version header takes longer as more versions exist because it loops through all versions."
[OK] Correct: Usually, the server uses a simple switch or map lookup, so checking a version is a quick fixed step, not a loop over all versions.
Understanding how version checks scale helps you explain API design choices clearly and shows you can think about performance in real systems.
"What if the server supported hundreds of versions and checked them by searching a list? How would the time complexity change?"