Ø Often a group of routes share a particular
characteristic — a certain authentication requirement, a path prefix, or
perhaps a controller namespace.
Ø Defining these shared characteristics again and
again on each route not only seems tedious but also can muddy up the shape of
your routes file and obscure some of the structures of your application.
Ø Route groups allow you to group several routes
together, and apply any shared configuration settings once to the entire group,
to reduce this duplication.
Ø Additionally, route groups are visual cues to
future developers (and to your own brain) that these routes are grouped
together.
Ø To group two or more routes together, you
“surround” the route definitions with a route group, as shown in Example 3-10. In reality, you’re actually passing a closure to
the group definition, and defining the grouped routes within that closure.
Route::group([], function () { Route::get('hello', function ()
{
return 'Hello';
});
Route::get('world', function ()
{
return 'World';
});
});
Ø By default, a route group doesn’t actually do
anything. There’s no difference between the group in Example 3-10 and separating a segment of your routes with code
comments.
Ø The empty array that’s the first parameter,
however, allows you to pass a variety of configuration settings that will apply
to the entire route group.
Middleware
Ø Probably the most common use for route groups is to
apply middleware to a group of routes. We’ll learn more about middleware in Chapter 10,
Ø but, among other things, they’re what Laravel uses
for authenticating users and restricting guest users from using certain parts
of a site.
Ø In Example 3-11, we’re creating
a route group around the dashboard and account views and applying the auth
middleware to both.
Ø In this example,
it means users have to be logged in to the application to view the dashboard or
the account page.
Route::group(['middleware' =>
'auth'], function () { Route::get('dashboard', function () {
return view('dashboard');
});
Route::get('account', function ()
{
return view('account');
});});
APPLYING MIDDLEWARE IN CONT ROLLERS
Ø Often it’s clearer and more direct to attach
middleware to your routes in the controller instead of at the route definition.
Ø You can do this by calling the middleware() method
in the constructor of your controller.
Ø The string you pass to the middleware() method is
the name of the middleware, and you can optionally chain modifier methods
(only() and except()) to define which methods will receive that middleware:
class DashboardController extends Controller
{
public function construct()
{
$this->middleware('auth');
$this->middleware('admin-auth')
->only('admin');
$this->middleware('team-member')
->except('admin');
}
}
Ø Note that, if you’re doing a lot of “only” and
“except” customizations, that’s often a sign that you should break out a new
controller for the exceptional routes.
Path Prefixes
Ø If you have a group of routes that share a segment
of their path — for example, if your site’s API is prefixed with /api — you can
use route groups to simplify this structure (see Example 3-12).
Route::group(['prefix' =>
'api'], function () { Route::get('/', function ()
{
// Handles the path /api
});
Route::get('users', function () {
// Handles the path /api/users
});
});
Ø Note that each prefixed group also has a / route that
represents the root of the prefix — in Example 3-12 that’s /api.
Subdomain Routing
Ø Subdomain routing is the same as route prefixing,
but it’s scoped by subdomain instead of route prefix.
Ø There are two primary uses for this. First, you may
want to present different sections of the application (or entirely different
applications) to different subdomains.
Example 3-13 shows how you can achieve this.
Route::group(['domain' =>
'api.myapp.com'], function () { Route::get('/', function () {
//
});
});
Ø Second, you might want to set part of the subdomain
as a parameter, as illustrated in Example 3-14.
Ø This is most
often done in cases of multitenancy (think Slack or Harvest, where each company
gets its own subdomain, like tighten.slack.co).
Route::group(['domain' =>
'{account}.myapp.com'], function () { Route::get('/', function ($account) {
//
});
Route::get('users/{id}',
function ($account,
$id) {
//
});
});
Ø Note that any parameters for the group get passed
into the grouped routes’ methods as the first parameter(s).
Namespace Prefixes
Ø When you’re grouping routes by subdomain or route
prefix, it’s likely their controllers have a similar PHP namespace.
Ø In the API example, all of the API routes’
controllers might be under an API namespace.
By using the route group namespace prefix, as shown in Example 3- 15, you can
avoid long controller references in groups like "API/ControllerA@
index" and "API/ControllerB@
index".
// App\Http\Controllers\ControllerA
Route::get('/', 'ControllerA@index');
Route::group(['namespace' =>
'API'], function () {
// App\Http\Controllers\API\ControllerB
Route::get('api/', 'ControllerB@index');
});
No comments:
Post a Comment