API versioning patterns in Laravel - Interactive Code Practice

Practice - 5 Tasks

1fill in blank

easy

Complete the code to define a versioned API route group in Laravel.

Laravel

Route::prefix('api/[1]')->group(function () {
    Route::get('/users', [UserController::class, 'index']);
});

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

Aapi

Bversion1

Cv1

Dusers

Attempts:

3 left

💡 Hint

Common Mistakes

Using 'api' as the version prefix instead of 'v1'.

Using resource names like 'users' as the version prefix.

In Laravel, API versioning often uses URL prefixes like 'v1' to separate versions.

2fill in blank

medium

Complete the code to specify the controller namespace for API version 2 routes.

Laravel

Route::prefix('api/v2')->namespace('[1]')->group(function () {
    Route::get('/products', [ProductController::class, 'index']);
});

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

AApp\Http\Controllers\API\V2

BApp\Http\Controllers\API\V1

CApp\Http\Controllers\Web

DApp\Http\Controllers

Attempts:

3 left

💡 Hint

Common Mistakes

Using the V1 namespace for V2 routes.

Using the Web namespace instead of API.

For version 2 API routes, the namespace usually reflects the version folder, like 'API\V2'.

3fill in blank

hard

Fix the error in the middleware assignment for API versioning.

Laravel

Route::prefix('api/v1')->middleware('[1]')->group(function () {
    Route::get('/orders', [OrderController::class, 'index']);
});

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

Aauth:web

Bauth:api

Cguest

Dverified

Attempts:

3 left

💡 Hint

Common Mistakes

Using 'auth:web' which is for web routes.

Using 'guest' which allows unauthenticated access.

API routes typically use 'auth:api' middleware to protect endpoints with API authentication.

4fill in blank

hard

Fill both blanks to create a versioned API route group with middleware and namespace.

Laravel

Route::prefix('api/[1]')->middleware('[2]')->namespace('App\\Http\\Controllers\\API\\[1]')->group(function () {
    Route::get('/items', [ItemController::class, 'index']);
});

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

Av3

Bauth:api

Cauth:web

Dv2

Attempts:

3 left

💡 Hint

Common Mistakes

Mismatching prefix and namespace versions.

Using 'auth:web' middleware for API routes.

The prefix and namespace should match the API version, here 'v3', and middleware should be 'auth:api' for API authentication.

5fill in blank

hard

Fill all three blanks to define a versioned API route with prefix, middleware, and controller namespace.

Laravel

Route::prefix('api/[1]')->middleware('[2]')->namespace('App\\Http\\Controllers\\API\\[1]')->group(function () {
    Route::post('/login', [[3]::class, 'authenticate']);
});

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

Av1

Bauth:api

CAuthController

Dauth:web

Attempts:

3 left

💡 Hint

Common Mistakes

Using 'auth:web' middleware for API routes.

Mismatching prefix and namespace versions.

Using wrong controller name.

API version prefix and namespace should be 'v1', middleware 'auth:api' for API protection, and the controller handling login is 'AuthController'.

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