Header-based versioning in Rest API - Step-by-Step Execution

Concept Flow - Header-based versioning

Client sends HTTP request

↓

Check 'Accept' header for version

↓

Match version in server code

↓

Process request with matched version

↓

Send response back to client

The client sends a request with a version in the header; the server reads it, matches the version, processes accordingly, and responds.

Execution Sample

Rest API

GET /api/resource HTTP/1.1
Host: example.com
Accept: application/vnd.example.v2+json

Client requests version 2 of the API resource using the Accept header.

Execution Table

Step	Action	Header Checked	Version Found	Server Behavior
1	Receive request	Accept: application/vnd.example.v2+json	v2	Proceed with version 2 logic
2	Process request	N/A	v2	Use v2 data format and rules
3	Send response	N/A	v2	Respond with v2 formatted data
4	End	N/A	N/A	Request completed

💡 Request ends after response is sent using the matched version logic.

Variable Tracker

Variable	Start	After Step 1	After Step 2	After Step 3	Final
request_headers	{}	{Accept: 'application/vnd.example.v2+json'}	{Accept: 'application/vnd.example.v2+json'}	{Accept: 'application/vnd.example.v2+json'}	{Accept: 'application/vnd.example.v2+json'}
api_version	null	v2	v2	v2	v2
response_data	null	null	v2 formatted data	v2 formatted data	v2 formatted data

Key Moments - 3 Insights

How does the server know which API version to use?

The server reads the 'Accept' header in the request (see execution_table step 1) to find the version string like 'v2'.

What happens if the 'Accept' header is missing or has no version?

The server may default to a base version or return an error; this is not shown here but would happen before processing (before step 2).

Why use header-based versioning instead of URL versioning?

Header-based versioning keeps URLs clean and allows clients to specify versions without changing endpoints, as shown by the version in the 'Accept' header.

Visual Quiz - 3 Questions

Look at the execution_table, what version does the server detect at step 1?

A v1

B v2

C v3

D No version

💡 Hint

Check the 'Version Found' column in execution_table row for step 1.

At which step does the server prepare the response data in the correct version format?

A Step 1

B Step 3

C Step 2

D Step 4

💡 Hint

Look at the 'Server Behavior' column for when data is formatted.

If the client sent 'Accept: application/vnd.example.v1+json', how would the 'api_version' variable change after step 1?

A It would be 'v1'

B It would be 'v2'

C It would be null

D It would be 'v3'

💡 Hint

Refer to variable_tracker for 'api_version' after step 1 and imagine the header value changed.

Concept Snapshot

Header-based versioning uses HTTP headers (like 'Accept') to specify API version.
Client sends version info in headers.
Server reads header, matches version.
Server processes request using matched version logic.
Response is sent in requested version format.
Keeps URLs clean and flexible.

Full Transcript

Header-based versioning means the client tells the server which API version it wants by sending a special header, usually the 'Accept' header. The server looks at this header to find the version number, like 'v2'. Then the server uses that version's rules to handle the request and sends back the response in the right format. This way, the URL stays the same, and the version is controlled by headers. In the example, the client sends 'Accept: application/vnd.example.v2+json', so the server uses version 2 logic. The execution table shows each step: receiving the request, checking the header, processing with version 2, and sending the response. Variables like 'api_version' track the version found. This method helps keep APIs clean and flexible.

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