API versioning patterns in Laravel - 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 patterns used in Laravel.

1. URI versioning (e.g., /api/v1/resource)
2. Header versioning (using custom headers)
3. Query parameter versioning (e.g., ?version=1)

beginner

How does URI versioning work in Laravel routes?

You include the version in the route URL, like /api/v1/users. Laravel routes are grouped by version prefix to separate versions cleanly.

intermediate

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

Header versioning keeps URLs clean and stable, hiding version details from the URL and allowing version changes without changing routes.

intermediate

How can Laravel middleware help with API versioning?

Middleware can inspect request headers or parameters to route requests to the correct version controller, centralizing version logic.

Which of these is NOT a common API versioning pattern?

A Cookie versioning

B Header versioning

C URI versioning

D Query parameter versioning

Cookie versioning is not a common pattern for API versioning. URI, header, and query parameter versioning are widely used.

In Laravel, how do you typically define routes for different API versions?

A Using different route files for each version

B Using route groups with version prefixes

C Using different controllers without route changes

D Using environment variables

Laravel uses route groups with version prefixes like /api/v1 to organize routes by API version.

What is a downside of URI versioning?

A It is hard to implement in Laravel

B It hides version info from clients

C It requires clients to change URLs when upgrading

D It does not support multiple versions

URI versioning requires clients to update URLs when switching API versions, which can be inconvenient.

Which Laravel feature can help route requests based on API version in headers?

A Blade templates

B Service providers

C Eloquent models

D Middleware

Middleware can read headers and direct requests to the correct version controller.

Why might query parameter versioning be less preferred?

A It can be ignored by caches

B It is not supported by Laravel

C It makes URLs longer and less clean

D It requires special headers

Query parameters can be ignored by some caches, causing caching issues for different API versions.

Explain how you would implement URI versioning in a Laravel API.

Think about how Laravel routes can be grouped and prefixed.

Describe the advantages and disadvantages of header versioning for APIs.

Consider how version info is hidden or shown to clients.

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