Header-based versioning in Rest API - Practice Problems & Coding Challenges

Challenge - 5 Problems

❓ Predict Output

intermediate

What is the output of this Flask API versioning code?

Consider this Flask API snippet using header-based versioning. What JSON response will the client receive when sending a request with header 'Accept-Version: v2'?

Rest API

from flask import Flask, request, jsonify
app = Flask(__name__)

@app.route('/data')
def data():
    version = request.headers.get('Accept-Version', 'v1')
    if version == 'v1':
        return jsonify({'message': 'Data from version 1'})
    elif version == 'v2':
        return jsonify({'message': 'Data from version 2', 'extra': 'Additional info'})
    else:
        return jsonify({'error': 'Unsupported version'}), 400

# Assume client sends header: Accept-Version: v2

A {"message": "Data from version 2", "extra": "Additional info"}

B HTTP 404 Not Found

C {"error": "Unsupported version"}

D {"message": "Data from version 1"}

💡 Hint

Check the header value and which branch the code executes.

The code checks the 'Accept-Version' header. If it is 'v2', it returns the JSON with message 'Data from version 2' and extra info. Other versions return different responses.

🧠 Conceptual

intermediate

Which header is commonly used for header-based API versioning?

In header-based versioning for REST APIs, which HTTP header is typically used to specify the API version?

A Authorization

B Content-Type

C Accept-Version

D User-Agent

💡 Hint

It is a custom header indicating the version the client wants.

The 'Accept-Version' header is commonly used to specify the API version in header-based versioning.

🔧 Debug

advanced

What error does this header-based versioning code raise?

This code snippet tries to read the API version from headers but has a bug. What error occurs when a request without the 'Accept-Version' header is sent?

Rest API

def get_version(request):
    version = request.headers['Accept-Version']
    if version == 'v1':
        return 'Version 1'
    else:
        return 'Other version'

# Request without 'Accept-Version' header

A KeyError

B TypeError

C ValueError

D No error, returns 'Other version'

💡 Hint

Accessing a missing dictionary key without a default causes an error.

Accessing request.headers['Accept-Version'] when the header is missing raises a KeyError.

📝 Syntax

advanced

Which option correctly extracts the API version from headers with a default fallback?

Choose the code snippet that safely gets the 'Accept-Version' header from a request, defaulting to 'v1' if missing.

A version = request.headers['Accept-Version'] or 'v1'

B version = request.headers.get('Accept-Version', 'v1')

C version = request.headers.get('Accept-Version') if 'Accept-Version' in request.headers else 'v1'

D version = request.headers['Accept-Version'] if request.headers['Accept-Version'] else 'v1'

💡 Hint

Use the dictionary get method with a default value.

Option B uses the .get() method with a default, which safely returns 'v1' if the header is missing.

🚀 Application

expert

How many different JSON keys are in the combined responses of this header-based versioning API?

Given this API code, how many unique JSON keys appear in all possible successful responses combined?

Rest API

def api_response(version):
    if version == 'v1':
        return {'status': 'ok', 'data': [1, 2, 3]}
    elif version == 'v2':
        return {'status': 'ok', 'data': [1, 2, 3], 'meta': {'count': 3}}
    elif version == 'v3':
        return {'status': 'ok', 'items': [1, 2, 3], 'meta': {'count': 3}}
    else:
        return {'error': 'Invalid version'}

# Consider only successful responses (no 'error' key)

A 6

B 5

C 3

D 4

💡 Hint

List all keys from each successful response and count unique ones.

Successful responses have keys: v1: status, data; v2: status, data, meta; v3: status, items, meta. Unique keys are status, data, meta, items → 4 keys total. But careful: v1 has 2 keys, v2 adds meta (3 keys), v3 replaces data with items (still unique), so total unique keys are status, data, meta, items → 4 keys. The question asks for combined unique keys, so answer is 4.

Practice

1. What is the main purpose of header-based versioning in REST APIs?

easy

A. To change the API URL structure for each version

B. To specify the API version using HTTP headers instead of URLs

C. To embed version info inside the request body

D. To use query parameters for version control

Solution

1. Step 1: Understand header-based versioning concept

   Header-based versioning uses HTTP headers to indicate which API version the client wants.

2. Step 2: Compare with other versioning methods

   Unlike URL or query parameter versioning, header-based keeps URLs clean and uses headers instead.

3. Final Answer:

   To specify the API version using HTTP headers instead of URLs -> Option B

4. Quick Check:

   Header versioning = version in HTTP headers [OK]

Hint: Remember: header versioning hides version in HTTP headers [OK]

Common Mistakes:

• Confusing header versioning with URL versioning
• Thinking version is in request body
• Assuming query parameters are used

2. Which HTTP header is commonly used to specify API version in header-based versioning?

easy

A. Content-Type

B. User-Agent

C. Accept

D. Authorization

Solution

1. Step 1: Identify common headers for versioning

   The Accept header is often used to specify the desired API version by content negotiation.

2. Step 2: Exclude unrelated headers

   Content-Type specifies data format sent, Authorization is for credentials, and User-Agent identifies client software.

3. Final Answer:

   Accept -> Option C

4. Quick Check:

   Version in Accept header = D [OK]

Hint: Version info usually goes in the Accept header [OK]

Common Mistakes:

• Using Content-Type instead of Accept for versioning
• Confusing Authorization with version header
• Thinking User-Agent controls version

3. Given this HTTP request header:
Accept: application/vnd.example.v2+json
Which API version is the client requesting?

medium

A. Version 2

B. Version 1

C. Version 3

D. No version specified

Solution

1. Step 1: Parse the Accept header value

   The value application/vnd.example.v2+json includes v2, indicating version 2.

2. Step 2: Confirm version number meaning

   The v2 part is a common pattern to specify version 2 of the API.

3. Final Answer:

   Version 2 -> Option A

4. Quick Check:

   v2 in Accept header means version 2 [OK]

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

Common Mistakes:

• Ignoring the 'v2' part and guessing version 1
• Assuming no version if not in URL
• Confusing +json suffix with version

4. A developer wrote this code snippet to check API version from headers:

version = request.headers.get('Content-Type')
if version == 'application/vnd.example.v1+json':
    return 'Version 1'
else:
    return 'Unknown version'

What is the main issue here?

medium

A. Using request.headers.get instead of request.get_header

B. Comparing version string incorrectly

C. Missing else condition

D. Using Content-Type header instead of Accept header for versioning

Solution

1. Step 1: Identify header used for versioning

   Header-based versioning typically uses the Accept header, not Content-Type.

2. Step 2: Explain why Content-Type is wrong here

   Content-Type describes the data format sent by the client, not the requested API version.

3. Final Answer:

   Using Content-Type header instead of Accept header for versioning -> Option D

4. Quick Check:

   Version header should be Accept, not Content-Type [OK]

Hint: Version info is in Accept header, not Content-Type [OK]

Common Mistakes:

• Checking Content-Type for version info
• Assuming request.headers.get is invalid
• Ignoring else branch

5. You want to support two API versions (v1 and v2) simultaneously using header-based versioning. Which approach correctly handles this in your server code?

hard

A. Check the Accept header for 'application/vnd.example.v1+json' or 'application/vnd.example.v2+json' and route accordingly

B. Use URL paths like /v1/resource and /v2/resource to separate versions

C. Ignore headers and always serve the latest version

D. Use query parameters like ?version=1 or ?version=2 to select version

Solution

1. Step 1: Understand header-based versioning goal

   It requires checking the HTTP headers to determine which API version to serve.

2. Step 2: Identify correct version detection method

   Checking the Accept header for specific version strings and routing requests accordingly is the right approach.

3. Final Answer:

   Check the Accept header for 'application/vnd.example.v1+json' or 'application/vnd.example.v2+json' and route accordingly -> Option A

4. Quick Check:

   Route by Accept header version strings [OK]

Hint: Route requests by Accept header version values [OK]

Common Mistakes:

• Mixing header versioning with URL or query parameter versioning
• Ignoring version headers and serving one version only
• Using wrong headers for version detection