Header-based versioning in Rest API - Interactive Code Practice

Practice - 5 Tasks

1fill in blank

easy

Complete the code to read the API version from the custom header.

Rest API

version = request.headers.get('[1]')

Drag options to blanks, or click blank then click option'

AAuthorization

BContent-Type

CAccept

DX-API-Version

Attempts:

3 left

💡 Hint

Common Mistakes

Using standard headers like 'Content-Type' or 'Accept' instead of a custom version header.

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

2fill in blank

medium

Complete the code to check if the API version is 'v2'.

Rest API

if version == '[1]':
    process_v2_request()

Drag options to blanks, or click blank then click option'

Av2

Bversion2

C2.0

Dversion_2

Attempts:

3 left

💡 Hint

Common Mistakes

Using 'version2' or '2.0' which are not the standard version strings.

The version string is usually short and simple like v2 to indicate version 2.

3fill in blank

hard

Fix the error in the code to correctly extract the version from headers.

Rest API

api_version = request.headers['[1]']

Drag options to blanks, or click blank then click option'

AX-API-Version

BAccept-Version

CVersion

DApi-Version

Attempts:

3 left

💡 Hint

Common Mistakes

Using incorrect header names like 'Version' or 'Api-Version' which do not exist.

The correct header key is X-API-Version to get the version value.

4fill in blank

hard

Fill both blanks to create a response that varies based on the API version header.

Rest API

if request.headers.get('[1]') == 'v1':
    return [2]('Response for version 1')

Drag options to blanks, or click blank then click option'

AX-API-Version

Bmake_response

Cjsonify

DResponse

Attempts:

3 left

💡 Hint

Common Mistakes

Using incorrect header names or response functions that do not return JSON.

The header X-API-Version is checked, and jsonify is used to create a JSON response.

5fill in blank

hard

Fill all three blanks to implement header-based versioning with default fallback.

Rest API

version = request.headers.get('[1]', '[2]')
if version == 'v1':
    return [3]({'message': 'Version 1 response'})

Drag options to blanks, or click blank then click option'

AX-API-Version

Bv1

Cjsonify

Dmake_response

Attempts:

3 left

💡 Hint

Common Mistakes

Not providing a default version or using wrong response functions.

The code reads the X-API-Version header with a default of v1, then returns a JSON response using jsonify.

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