API versioning strategies in Node.js - Cheat Sheet & Quick Revision

Recall & Review

beginner

What is API versioning and why is it important?

API versioning is a way to manage changes in an API over time. It helps keep old clients working while allowing new features or fixes in newer versions.

beginner

Name three common API versioning strategies.

1. URI versioning (e.g., /v1/resource)
2. Query parameter versioning (e.g., /resource?version=1)
3. Header versioning (using custom headers like 'Accept-Version')

beginner

How does URI versioning work in an API?

URI versioning adds the version number directly in the URL path, like /api/v1/users. This makes it clear and easy to route requests to the right version.

intermediate

What is a benefit of using header versioning over URI versioning?

Header versioning keeps URLs clean and lets clients specify the version in request headers, which can be more flexible and hides version details from the URL.

intermediate

What is a drawback of query parameter versioning?

Query parameter versioning can be less visible and sometimes caching systems might ignore query parameters, causing unexpected behavior.

Which API versioning strategy places the version number in the URL path?

A Query parameter versioning

B Header versioning

C URI versioning

D Content negotiation

URI versioning adds the version directly in the URL path, like /v1/resource.

What header might be used for header-based API versioning?

A Accept-Version

B Content-Type

C Authorization

D User-Agent

Custom headers like 'Accept-Version' are used to specify API version in header versioning.

Which versioning strategy can cause issues with caching if not handled properly?

A URI versioning

B Query parameter versioning

C Header versioning

D No versioning

Query parameters might be ignored by some caches, causing stale or wrong responses.

Why is API versioning important?

A To avoid documentation

B To break all old clients

C To make URLs longer

D To allow changes without breaking existing clients

Versioning lets you improve your API while keeping old clients working.

Which versioning method keeps URLs clean and hides version info from the URL?

A Header versioning

B Query parameter versioning

C URI versioning

D No versioning

Header versioning uses request headers to specify version, keeping URLs clean.

Explain three common API versioning strategies and when you might use each.

Think about how the version appears in the request and what clients see.

Describe why API versioning is necessary and what problems it solves.

Imagine you change your app but some users still use the old one.

Practice

1. Which of the following is the simplest and most common method to version a Node.js API?

easy

A. Using content negotiation with the Accept header

B. Using a custom HTTP header to specify the version

C. Adding a version query parameter, like ?version=1

D. Including the version number in the URL path, like /v1/users

Solution

1. Step 1: Understand common API versioning methods

   API versioning can be done via URL path, headers, query params, or content negotiation.

2. Step 2: Identify the simplest and most common method

   Including the version in the URL path is easiest to implement and understand.

3. Final Answer:

   Including the version number in the URL path, like /v1/users -> Option D

4. Quick Check:

   URL path versioning = simplest method [OK]

Hint: URL path versioning is easiest to spot and use [OK]

Common Mistakes:

• Thinking headers are simpler for beginners
• Confusing query params with URL path
• Assuming content negotiation is the default

2. Which syntax correctly defines a route in Express.js for version 2 of an API using URL path versioning?

easy

A. app.get('/api/v2/users', (req, res) => { res.send('v2 users'); });

B. app.get('/api/users?v=2', (req, res) => { res.send('v2 users'); });

C. app.get('/api/users', (req, res) => { if(req.headers['version'] === '2') res.send('v2 users'); });

D. app.get('/api/users', (req, res) => { res.send('v2 users'); });

Solution

1. Step 1: Recognize URL path versioning syntax in Express.js

   Version 2 in URL path means the route includes /v2/ in the path.

2. Step 2: Match the correct route definition

   app.get('/api/v2/users', (req, res) => { res.send('v2 users'); }); uses /api/v2/users which matches version 2 in the URL path.

3. Final Answer:

   app.get('/api/v2/users', (req, res) => { res.send('v2 users'); }); -> Option A

4. Quick Check:

   URL path versioning route = app.get('/api/v2/users', (req, res) => { res.send('v2 users'); }); [OK]

Hint: Version in URL path means it appears in the route string [OK]

Common Mistakes:

• Using query params instead of URL path
• Checking headers inside route without version in path
• Ignoring version in route path

3. Given this Express.js code snippet, what will be the response when a client requests /api/users with header Accept-Version: 2?

const express = require('express');
const app = express();

app.get('/api/users', (req, res) => {
  if (req.headers['accept-version'] === '2') {
    res.send('Users v2');
  } else {
    res.send('Users v1');
  }
});

medium

A. "Users v1"

B. 404 Not Found

C. "Users v2"

D. Error: Missing version

Solution

1. Step 1: Check the header condition in the route handler

   The code checks if req.headers['accept-version'] equals '2'.

2. Step 2: Determine response based on header value

   If header is '2', it sends 'Users v2'; otherwise, 'Users v1'. The request has header 'Accept-Version: 2'.

3. Final Answer:

   "Users v2" -> Option C

4. Quick Check:

   Header 'Accept-Version: 2' triggers v2 response [OK]

Hint: Match header value exactly to get correct version response [OK]

Common Mistakes:

• Ignoring case sensitivity of header keys
• Assuming URL path versioning instead of header
• Expecting 404 when route exists

4. Identify the bug in this Express.js versioning code using query parameters:

app.get('/api/users', (req, res) => {
  if (req.query.version = '1') {
    res.send('Users v1');
  } else {
    res.send('Users v2');
  }
});

medium

A. Missing route for version 2 explicitly

B. Using assignment (=) instead of comparison (== or ===) in the if condition

C. Incorrect query parameter name; should be 'ver' not 'version'

D. res.send should be res.json for API responses

Solution

1. Step 1: Examine the if condition syntax

   The condition uses = which assigns '1' to req.query.version instead of comparing.

2. Step 2: Understand the effect of assignment in condition

   Assignment returns '1' (truthy), so the if block always runs, ignoring else.

3. Final Answer:

   Using assignment (=) instead of comparison (== or ===) in the if condition -> Option B

4. Quick Check:

   Use '==' or '===' for comparison, not '=' [OK]

Hint: Use triple equals (===) for comparisons, not single equals (=) [OK]

Common Mistakes:

• Confusing assignment with equality check
• Assuming missing else block causes bug
• Thinking res.send vs res.json causes error here

5. You want to support two API versions in your Node.js app: v1 uses URL path versioning, and v2 uses a custom header X-API-Version. How should you design your Express routes to handle both cleanly?

hard

A. Define separate routes: /api/v1/... for v1, and /api/... with header check for v2

B. Use only URL path versioning for both versions to avoid confusion

C. Use query parameters for v1 and headers for v2 in the same route

D. Combine both version indicators in the URL path like /api/v1/v2/...

Solution

1. Step 1: Separate versioning methods logically

   Use URL path for v1 routes explicitly, e.g., /api/v1/....

2. Step 2: Use header check for v2 on routes without version in path

   Define routes like /api/... and check X-API-Version header to serve v2.

3. Final Answer:

   Define separate routes: /api/v1/... for v1, and /api/... with header check for v2 -> Option A

4. Quick Check:

   Separate routes for path and header versioning [OK]

Hint: Separate routes for path versioning; use header check for others [OK]

Common Mistakes:

• Mixing both versions in one URL path
• Using query params inconsistently
• Ignoring header version check in routes