API versioning patterns in Laravel - Practice Problems & Coding Challenges

Challenge - 5 Problems

❓ component_behavior

intermediate

How does Laravel route versioning affect API response?

Given these Laravel routes for API versioning, what will be the output when calling /api/v2/users?

Route::prefix('api/v1')->group(function () {
    Route::get('users', fn() => 'Users from v1');
});
Route::prefix('api/v2')->group(function () {
    Route::get('users', fn() => 'Users from v2');
});

Laravel

Route::prefix('api/v1')->group(function () {
    Route::get('users', fn() => 'Users from v1');
});
Route::prefix('api/v2')->group(function () {
    Route::get('users', fn() => 'Users from v2');
});

A Returns 'Users from v2'

B Returns 'Users from v1'

C Returns a 404 Not Found error

D Returns both 'Users from v1' and 'Users from v2' concatenated

💡 Hint

Check which route prefix matches the requested URL.

The route with prefix 'api/v2' matches the URL '/api/v2/users', so it returns 'Users from v2'.

📝 Syntax

intermediate

Identify the correct Laravel route versioning syntax

Which option correctly defines a versioned API route for version 3 in Laravel?

A Route::prefix('api/v3')->group(function () { Route::get('items', fn() => 'v3 items'); });

B Route::version('v3')->group(function () { Route::get('items', fn() => 'v3 items'); });

C Route::group('api/v3', function () { Route::get('items', fn() => 'v3 items'); });

D Route::apiVersion('v3')->group(function () { Route::get('items', fn() => 'v3 items'); });

💡 Hint

Laravel uses prefix to group routes under a URL segment.

Option A uses the correct prefix method to group routes under 'api/v3'. Other options use non-existent methods.

🔧 Debug

advanced

Why is this Laravel API versioning code not recommended?

Consider this Laravel route setup:

Route::prefix('api')->group(function () {
    Route::get('v1/users', fn() => 'v1 users');
    Route::get('v2/users', fn() => 'v2 users');
});

Why is this not the preferred pattern for API versioning?

Laravel

Route::prefix('api')->group(function () {
    Route::get('v1/users', fn() => 'v1 users');
    Route::get('v2/users', fn() => 'v2 users');
});

A Because the route definitions are missing a namespace declaration

B Because the route prefix 'api' conflicts with the version in the path, causing no match

C Because the HTTP method GET is not allowed for these routes

D Because the route should use nested prefix groups for versions instead of including version in path

💡 Hint

Think about how Laravel matches prefixes and paths.

Including version in the path inside a prefix group can cause confusion. Nesting prefix groups for 'v1' and 'v2' inside 'api' is the correct pattern.

❓ state_output

advanced

What is the output of this Laravel API versioning middleware example?

Given this middleware that sets API version in request and this route:

class ApiVersionMiddleware {
    public function handle($request, $next) {
        $version = $request->header('Accept-Version', 'v1');
        $request->merge(['api_version' => $version]);
        return $next($request);
    }
}

Route::middleware([ApiVersionMiddleware::class])->group(function () {
    Route::get('api/users', function ($request) {
        return 'Version: ' . $request->api_version;
    });
});

What will be the output when calling /api/users with header Accept-Version: v2?

Laravel

class ApiVersionMiddleware {
    public function handle($request, $next) {
        $version = $request->header('Accept-Version', 'v1');
        $request->merge(['api_version' => $version]);
        return $next($request);
    }
}

Route::middleware([ApiVersionMiddleware::class])->group(function () {
    Route::get('api/users', function ($request) {
        return 'Version: ' . $request->api_version;
    });
});

A Version: null

B Version: v1

C Version: v2

D Throws an error due to missing api_version property

💡 Hint

Check how the middleware reads and sets the version from headers.

The middleware reads the 'Accept-Version' header and sets 'api_version' in the request. The route returns this value.

🧠 Conceptual

expert

Which Laravel API versioning pattern best supports backward compatibility?

Among these API versioning patterns in Laravel, which one best supports backward compatibility while allowing new features?

A No versioning, always update the same endpoints

B URI versioning using route prefixes like /api/v1/, /api/v2/

C Query parameter versioning like /api/users?version=1

D Header versioning using custom headers like Accept-Version

💡 Hint

Think about how clients can choose which API version to call.

URI versioning with route prefixes clearly separates versions, allowing old clients to keep using old versions while new clients use new ones.

Practice

1. Which of the following is a common pattern for API versioning in Laravel?

easy

A. Changing database schema for each API version

B. Using URL prefixes like /api/v1/ to separate versions

C. Using different PHP files for each API version

D. Hardcoding version numbers inside controller methods

Solution

1. Step 1: Understand common API versioning methods

   API versioning often uses URL prefixes, query parameters, or headers to separate versions.

2. Step 2: Identify Laravel's typical approach

   Laravel commonly uses route groups with URL prefixes like /api/v1/ to manage versions cleanly.

3. Final Answer:

   Using URL prefixes like /api/v1/ to separate versions -> Option B

4. Quick Check:

   URL prefix versioning = A [OK]

Hint: Look for URL prefix usage in routes for versioning [OK]

Common Mistakes:

• Confusing database changes with API versioning
• Thinking versioning requires separate PHP files
• Embedding version logic inside controllers

2. Which is the correct way to define a versioned API route group in Laravel using URL prefix?

easy

A. Route::version('v1')->group(function () { Route::get('/users', ...); });

B. Route::apiVersion('v1', function () { Route::get('/users', ...); });

C. Route::prefix('v1')->group(function () { Route::get('/users', ...); });

D. Route::group('version:v1', function () { Route::get('/users', ...); });

Solution

1. Step 1: Recall Laravel route group syntax

   Laravel uses Route::prefix('prefix')->group(function() {...}) to group routes under a URL prefix.

2. Step 2: Match versioning syntax

   Using prefix('v1') correctly sets the URL prefix for version 1 routes.

3. Final Answer:

   Route::prefix('v1')->group(function () { Route::get('/users', ...); }); -> Option C

4. Quick Check:

   Route prefix method = B [OK]

Hint: Remember Laravel uses prefix() for URL grouping [OK]

Common Mistakes:

• Using non-existent methods like version() or apiVersion()
• Passing version as a string to group() directly
• Confusing middleware with prefix for versioning

3. Given this Laravel route group:

Route::prefix('api/v2')->group(function () {
    Route::get('/products', function () {
        return 'Version 2 Products';
    });
});

What will be the response when accessing /api/v2/products?

medium

A. "Version 2 Products"

B. 404 Not Found error

C. "Version 1 Products"

D. 500 Internal Server Error

Solution

1. Step 1: Analyze the route prefix and path

   The route is grouped under prefix api/v2 and defines a GET route for /products.

2. Step 2: Match the URL to the route

   Accessing /api/v2/products matches this route and returns the string 'Version 2 Products'.

3. Final Answer:

   "Version 2 Products" -> Option A

4. Quick Check:

   Route prefix + path = Version 2 Products [OK]

Hint: Match full URL with prefix + route path [OK]

Common Mistakes:

• Assuming version 1 response without checking prefix
• Expecting error due to missing controller
• Confusing route path with prefix

4. What is wrong with this Laravel API versioning route definition?

Route::group(['prefix' => 'api/v1'], function () {
    Route::get('/users', 'UserController@index');
});
Route::group(['prefix' => 'api/v1'], function () {
    Route::get('/users', 'UserController@list');
});

medium

A. Route groups cannot share the same prefix

B. Prefix should be 'v1/api' not 'api/v1'

C. Controller methods must be named 'show' or 'index' only

D. Duplicate routes with same URL and method cause conflicts

Solution

1. Step 1: Identify route conflicts

   Both route groups define GET routes for /api/v1/users but point to different controller methods.

2. Step 2: Understand Laravel routing behavior

   Laravel cannot distinguish between these two identical routes, causing conflicts or unexpected behavior.

3. Final Answer:

   Duplicate routes with same URL and method cause conflicts -> Option D

4. Quick Check:

   Duplicate route URLs = conflict [OK]

Hint: Avoid duplicate routes with same method and path [OK]

Common Mistakes:

• Thinking prefix order matters for routing
• Believing controller method names are restricted
• Assuming route groups cannot share prefixes

5. You want to support two API versions in Laravel: v1 and v2. Version 1 returns all users, version 2 returns only active users. Which is the best way to organize routes and controllers?

hard

A. Use route groups with prefixes /api/v1 and /api/v2, each pointing to separate controllers handling version logic

B. Use a single route /api/users and check version in controller to return different data

C. Use query parameter ?version=1 and switch logic inside one controller method

D. Create separate Laravel projects for each API version

Solution

1. Step 1: Understand maintainability and clarity

   Separating versions by route prefix and controllers keeps code clean and easy to maintain.

2. Step 2: Evaluate other options

   Single route with version checks or query parameters mixes logic and complicates code. Separate projects add unnecessary overhead.

3. Final Answer:

   Use route groups with prefixes /api/v1 and /api/v2, each pointing to separate controllers handling version logic -> Option A

4. Quick Check:

   Separate prefixes + controllers = clean versioning [OK]

Hint: Group routes by prefix and separate controllers per version [OK]

Common Mistakes:

• Mixing version logic inside one controller
• Using query parameters for versioning in Laravel routes
• Splitting versions into separate projects unnecessarily