Versioning best practices in Rest API - Practice Problems & Coding Challenges

Challenge - 5 Problems

❓ Predict Output

intermediate

What is the output of this API versioning example?

Consider a REST API that uses URL path versioning. The client requests /api/v2/users. The server code routes this to the version 2 handler, which returns a JSON list of users with an added email field.

What JSON response will the client receive?

Rest API

def get_users(version):
    if version == 'v1':
        return [{'id': 1, 'name': 'Alice'}, {'id': 2, 'name': 'Bob'}]
    elif version == 'v2':
        return [{'id': 1, 'name': 'Alice', 'email': '[e-mail]'}, {'id': 2, 'name': 'Bob', 'email': '[e-mail]'}]

response = get_users('v2')
print(response)

A [{'id': 1, 'name': 'Alice'}, {'id': 2, 'name': 'Bob'}]

B Error: Version not supported

C [{'id': 1, 'name': 'Alice', 'email': '[e-mail]'}, {'id': 2, 'name': 'Bob', 'email': '[e-mail]'}]

D []

💡 Hint

Check which version the function returns with the email field included.

Version 2 adds the email field to each user. Since the client requested v2, the response includes emails.

🧠 Conceptual

intermediate

Which versioning method is best for backward compatibility?

There are several ways to version REST APIs: URL path versioning, query parameter versioning, and header versioning.

Which method is generally considered best for maintaining backward compatibility and clean URLs?

A Using URL path versioning like /api/v1/resource

B Using query parameters like /api/resource?version=1

C Using custom headers like X-API-Version: 1

D No versioning, just update the API directly

💡 Hint

Think about what makes URLs clear and easy to cache.

URL path versioning clearly separates versions and is easy to cache and document, making it best for backward compatibility.

🔧 Debug

advanced

Why does this API versioning code return 'default handler' unexpectedly?

The following Python code tries to parse the API version from a header and route the request. It returns 'default handler' even though the header has value 2. Why?

Rest API

def route_request(headers):
    version = headers.get('X-API-Version')
    if version == '1':
        return 'v1 handler'
    elif version == '2':
        return 'v2 handler'
    else:
        return 'default handler'

headers = {'X-API-Version': 2}
print(route_request(headers))

A SyntaxError due to missing colon

B KeyError because 'X-API-Version' is missing

C TypeError because header value is int, not string

D Returns 'default handler' because version is int, not string

💡 Hint

Check the type of the header value and how it is compared.

The header value is an integer 2, but the code compares it to strings '1' and '2'. Since 2 == '2' is False, it falls to the 'default handler'.

📝 Syntax

advanced

Which option correctly defines a versioned API route in Flask?

Given Flask web framework, which route decorator correctly defines a versioned API endpoint for version 1?

Rest API

from flask import Flask
app = Flask(__name__)

@app.route('/api/v1/users')
def get_users():
    return 'Users v1'

A @app.route('/api/users?version=1')

B @app.route('/api/v1/users')

C @app.route('/api/users/v1')

D @app.route('/api/users', version='1')

💡 Hint

Think about how URL paths are defined in Flask routes.

Flask routes match URL paths literally. Version in the path should come before the resource name for clarity.

🚀 Application

expert

How many distinct API versions are supported by this versioning logic?

Consider this API versioning logic in pseudocode:

if 'version' in request.headers:
    if request.headers['version'] in ['1', '2', '3']:
        use that version
    else:
        use default version 1
else:
    use default version 1

How many distinct API versions can clients explicitly request?

A 3

B 4

C 1

D 0

💡 Hint

Count the versions listed in the allowed list.

The code allows clients to request versions '1', '2', or '3' explicitly. Any other or missing version defaults to '1'.

Practice

1. What is the main reason to use versioning in a REST API?

easy

A. To hide the API from users

B. To make the API faster

C. To reduce the number of API endpoints

D. To keep the API stable and avoid breaking existing clients

Solution

1. Step 1: Understand API stability

   Versioning helps keep the API stable by allowing changes without breaking existing users.

2. Step 2: Identify the main goal of versioning

   The main goal is to avoid breaking existing clients when the API changes.

3. Final Answer:

   To keep the API stable and avoid breaking existing clients -> Option D

4. Quick Check:

   Versioning = Stability [OK]

Hint: Versioning protects old users from breaking changes [OK]

Common Mistakes:

• Thinking versioning makes API faster
• Believing versioning reduces endpoints
• Assuming versioning hides the API

2. Which of the following is a correct way to include versioning in a REST API URL?

easy

A. /api/v1/users

B. /api/users/v1

C. /v1/api/users

D. /users/api/v1

Solution

1. Step 1: Identify common versioning URL pattern

   The standard practice is to put the version right after the base API path, like /api/v1/.

2. Step 2: Check each option

   Only /api/v1/users follows the common pattern where version is after /api/.

3. Final Answer:

   /api/v1/users -> Option A

4. Quick Check:

   Version in URL path = /api/v1/ [OK]

Hint: Version usually goes right after /api/ in URL [OK]

Common Mistakes:

• Placing version after resource name
• Putting version before /api/
• Adding version at the end of URL

3. Given this API request header: Accept: application/vnd.example.v2+json, what version of the API is being requested?

medium

A. Version 3

B. Version 1

C. Version 2

D. No version specified

Solution

1. Step 1: Analyze the Accept header format

   The header uses media type versioning with 'v2' indicating version 2.

2. Step 2: Identify the version number

   The 'v2' in 'application/vnd.example.v2+json' means version 2 is requested.

3. Final Answer:

   Version 2 -> Option C

4. Quick Check:

   Header v2 means API version 2 [OK]

Hint: Look for 'v' followed by number in Accept header [OK]

Common Mistakes:

• Ignoring 'v2' and assuming version 1
• Confusing media type with version
• Assuming no version if not in URL

4. You have an API that uses URL versioning like /api/v1/resource. You want to upgrade to version 2 but keep version 1 working. What is the best fix if your current code overwrites the version path and breaks v1?

medium

A. Create separate routes for /api/v1/resource and /api/v2/resource

B. Remove version from URL and use query parameters instead

C. Only keep /api/v2/resource and delete /api/v1/resource

D. Use the same code for both versions without changes

Solution

1. Step 1: Understand versioning goal

   Versioning allows multiple versions to coexist so old clients keep working.

2. Step 2: Fix route handling

   Separate routes for each version keep both versions working without conflict.

3. Final Answer:

   Create separate routes for /api/v1/resource and /api/v2/resource -> Option A

4. Quick Check:

   Separate routes = keep versions working [OK]

Hint: Keep old and new versions on separate routes [OK]

Common Mistakes:

• Overwriting old version routes
• Removing version info completely
• Using same code for different versions

5. You want to design an API versioning strategy that allows clients to specify the version either in the URL path or in a custom header. Which approach best follows versioning best practices?

hard

A. Ignore versioning and always use the latest API version

B. Support both methods but clearly document and prefer one as primary

C. Allow clients to mix URL and header versions freely without restrictions

D. Use query parameters for versioning only

Solution

1. Step 1: Understand consistency in versioning

   Best practice is to be consistent and clear about versioning methods.

2. Step 2: Choose a primary versioning method

   Supporting both but preferring one and documenting it helps developers avoid confusion.

3. Final Answer:

   Support both methods but clearly document and prefer one as primary -> Option B

4. Quick Check:

   Clear, consistent versioning = best practice [OK]

Hint: Pick one versioning method as main, document it well [OK]

Common Mistakes:

• Mixing versions without clear rules
• Ignoring versioning and breaking clients
• Using only query parameters without reason