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.