API Versioning in Laravel 11
With the release of Laravel 11, the application skeleton was slimmed down to remove extra files that aren't required on every project. Part of that change removed all service providers from the application source code except the AppServiceProvider
.
Another part of the updated application skeleton is removing API routes in the default installation. Suppose you plan on adding an API to your application or exclusively writing an API with Laravel. In that case, you can set up the api
middleware group and routes with an Artisan command:
<!-- Syntax highlighted by torchlight.dev -->php artisan install:api
The install:api
sets up the api.php
route file (and configures it), a database migration for personal access tokens, and a sanctum configuration file. If you don't need to version your API, that's all you need to do.
#Versioning Your API in Separate Files
A common approach to writing versioned APIs in Laravel is separating routes into different files. Doing so simplifies the overhead of reasoning about a specific API version and keeps things tidy. In Laravel 10 or earlier, a common approach is adding additional route files for each API version to the RouteServiceProvider
:
<!-- Syntax highlighted by torchlight.dev -->$this->routes(function () { Route::middleware('api') ->prefix('api') ->group(base_path('routes/api.php')); Route::middleware('api') ->prefix('api/v1') ->group(base_path('routes/api_v1.php')); Route::middleware('api') ->prefix('api/v2') ->group(base_path('routes/api_v2.php')); Route::middleware('web') ->group(base_path('routes/web.php')); });
In the above example, the routes/api.php
typically offers a /user
endpoint for Laravel sanctum, and the remainder of API routes are tucked in the appropriate version.
#Versioning Your API in Laravel 11
With route bootstrapping moving out of the RouteServiceProvider
and into bootstrap/app.php,
here are a few ways you can version your API.
First, let's generate a few files to demonstrate setting up routing:
<!-- Syntax highlighted by torchlight.dev -->touch routes/api_v1.php touch routes/api_v2.php php artisan make:controller --api Api/V1/PostsController php artisan make:controller --api Api/V2/PostsController
Use whatever file name convention and location that suits you.
Next, open the routes/api.php
file and add the following lines to the bottom of the file:
<!-- Syntax highlighted by torchlight.dev -->Route::prefix('v1')->group(base_path('routes/api_v1.php')); Route::prefix('v2')->group(base_path('routes/api_v2.php'));
The above code being in api.php
means that we are already working within the api
route prefix and using the api
middleware group.
Next, let's add the example routes for each respective API version so we can visualize the route list for each version.
Here's the api_v1.php
file:
<!-- Syntax highlighted by torchlight.dev --><?php use App\Http\Controllers\Api\V1\PostsController; Route::apiResource('posts', PostsController::class);
And the api_v2.php
file:
<!-- Syntax highlighted by torchlight.dev --><?php use App\Http\Controllers\Api\V2\PostsController; Route::apiResource('posts', PostsController::class);
With our route files defined, running route:list
, we can see versioned routes!
Pro tip: you can isolate versioned routes using the --path
flag, making it easy to focus on a specific API version:
<!-- Syntax highlighted by torchlight.dev -->php artisan route:list --path=api/v1 php artisan route:list --path=api/v2
Check out how tidy it looks if you just output routes for api/v2
:
#Defining Versioned Routes in the App Bootstrap File
Another approach I've seen is defining additional API routes in the bootstrap/app.php
file using the then:
argument, which accepts a Closure
:
<!-- Syntax highlighted by torchlight.dev -->php artisan install:api
I prefer adding additional route files directly to routes/api.php
, but this is another approach that would work. When defining routes in the bootstrap file, these groups aren't configured to use the api
middleware group. Make sure to include the api
middleware group with these routes!
The above is the detailed content of API Versioning in Laravel 11. For more information, please follow other related articles on the PHP Chinese website!

Hot AI Tools

Undresser.AI Undress
AI-powered app for creating realistic nude photos

AI Clothes Remover
Online AI tool for removing clothes from photos.

Undress AI Tool
Undress images for free

Clothoff.io
AI clothes remover

Video Face Swap
Swap faces in any video effortlessly with our completely free AI face swap tool!

Hot Article

Hot Tools

Notepad++7.3.1
Easy-to-use and free code editor

SublimeText3 Chinese version
Chinese version, very easy to use

Zend Studio 13.0.1
Powerful PHP integrated development environment

Dreamweaver CS6
Visual web development tools

SublimeText3 Mac version
God-level code editing software (SublimeText3)

Hot Topics

Alipay PHP...

JWT is an open standard based on JSON, used to securely transmit information between parties, mainly for identity authentication and information exchange. 1. JWT consists of three parts: Header, Payload and Signature. 2. The working principle of JWT includes three steps: generating JWT, verifying JWT and parsing Payload. 3. When using JWT for authentication in PHP, JWT can be generated and verified, and user role and permission information can be included in advanced usage. 4. Common errors include signature verification failure, token expiration, and payload oversized. Debugging skills include using debugging tools and logging. 5. Performance optimization and best practices include using appropriate signature algorithms, setting validity periods reasonably,

Session hijacking can be achieved through the following steps: 1. Obtain the session ID, 2. Use the session ID, 3. Keep the session active. The methods to prevent session hijacking in PHP include: 1. Use the session_regenerate_id() function to regenerate the session ID, 2. Store session data through the database, 3. Ensure that all session data is transmitted through HTTPS.

The application of SOLID principle in PHP development includes: 1. Single responsibility principle (SRP): Each class is responsible for only one function. 2. Open and close principle (OCP): Changes are achieved through extension rather than modification. 3. Lisch's Substitution Principle (LSP): Subclasses can replace base classes without affecting program accuracy. 4. Interface isolation principle (ISP): Use fine-grained interfaces to avoid dependencies and unused methods. 5. Dependency inversion principle (DIP): High and low-level modules rely on abstraction and are implemented through dependency injection.

How to automatically set the permissions of unixsocket after the system restarts. Every time the system restarts, we need to execute the following command to modify the permissions of unixsocket: sudo...

How to debug CLI mode in PHPStorm? When developing with PHPStorm, sometimes we need to debug PHP in command line interface (CLI) mode...

Static binding (static::) implements late static binding (LSB) in PHP, allowing calling classes to be referenced in static contexts rather than defining classes. 1) The parsing process is performed at runtime, 2) Look up the call class in the inheritance relationship, 3) It may bring performance overhead.

Sending JSON data using PHP's cURL library In PHP development, it is often necessary to interact with external APIs. One of the common ways is to use cURL library to send POST�...
