Routing and Controllers

Every page, API endpoint, and form action in a Laravel app starts the same way: a line in routes/web.php that pairs an HTTP verb with a URI and says what handles it. The skeleton you built in Creating a Laravel Project boots and returns 404 for everything you type into the browser; a route is what closes that gap. In Laravel 11+, routes/web.php is loaded by default through withRouting in bootstrap/app.php; routes/api.php is not registered until you run php artisan install:api, which publishes it plus the api middleware group.

use App\Http\Controllers\OrderController;
use Illuminate\Support\Facades\Route;

Route::get('/orders', [OrderController::class, 'index']);
Route::get('/orders/{order}', [OrderController::class, 'show']);
Route::post('/orders', [OrderController::class, 'store']);

Each line is a verb + URI + handler triple. The verb is the HTTP method — get, post, put, patch, delete. The URI has no leading-slash segment confusion: you write '/orders' or 'orders', both register the same path. The handler is either a closure or a Controller@method pair.

Closures are right for one-off pages and quick spikes:

Route::get('/health', fn () => response()->json(['ok' => true]));

But controllers are the default for anything with logic, because controllers can be type-hinted for dependency injection, organized by resource, and — critically — cached. Route caching is one of the reasons closures are discouraged in real apps: php artisan route:cache fails on routes that define closures, because the cached route file is serialized and closures cannot be serialized. A route closure in a production app blocks one of the cheapest performance wins Laravel offers.

Matching happens in registration order. Two routes with the same verb and URI — the first one wins:

Route::get('/orders/latest', [OrderController::class, 'latest']);
Route::get('/orders/{order}', [OrderController::class, 'show']); // {order} never matches 'latest' if 'latest' is declared first

Declare static paths before parameterized ones. If you reverse them, /orders/latest matches {order} and you spend an afternoon wondering why Order::findOrFail('latest') throws a 404.

When you need the full picture of what is registered, ask artisan:

php artisan route:list
php artisan route:list --path=orders
php artisan route:list -v          # includes middleware per route

The output lists Method, URI, Name, Action, and Middleware for every registered route. It is the fastest way to answer "what URL do I call?" and "which middleware runs on this endpoint?" without reading any code. If a route "does not exist" in the browser but route:list shows it, the problem is usually a wrong APP_URL, a missing install:api for API routes, or a stale route:cache.

Route files can also be split for larger apps. Laravel 11 lets you register extra route files in bootstrap/app.php:

->withRouting(
    web: __DIR__.'/../routes/web.php',
    api: __DIR__.'/../routes/api.php',
    channels: __DIR__.'/../routes/channels.php',
    commands: __DIR__.'/../routes/console.php',
    health: '/up',
)

Each file gets its own middleware stack: routes in web.php receive session and CSRF middleware, while api.php routes receive stateless middleware and the throttle:api limiter. That split is why a cookie session works on web routes but does not automatically authenticate an API request — the two files run through different groups, and knowing which group your route landed in answers a whole class of auth bugs. If an endpoint "forgets" the logged-in user between requests, check the middleware group before you suspect the session driver.

Verb semantics are worth one more pass because interviewers like them. GET must be safe and idempotent — browsers, proxies, and crawlers prefetch GETs, so a GET that mutates data will be triggered without your consent. POST creates, PUT replaces, PATCH partially updates, and DELETE removes. Laravel accepts PUT and PATCH interchangeably in resource routes, but the semantics still matter for API design: a client can assume PATCH will not wipe fields you omitted, while PUT is expected to send the full representation.

A URI like /orders/{order} declares a parameter. Laravel injects it into the handler by name — closure parameters and controller method parameters are matched to the URI segments by position and name:

Route::get('/orders/{order}', function (string $order) {
    return Order::findOrFail($order);
});

That works, but it makes you call findOrFail by hand on every route. Route model binding does it for you. Type-hint the parameter as a model and Laravel resolves it — implicit binding runs a query on the model's route key (the id column by default) and hands you a live model, or a 404 if nothing matches:

Route::get('/orders/{order}', function (App\Models\Order $order) {
    return view('orders.show', compact('order'));
});

No findOrFail, no manual query, no use noise in the body. If the id does not exist, Laravel throws ModelNotFoundException, which the exception handler converts to a NotFoundHttpException — an HTTP 404 page. That conversion is why model binding never leaks a 500 to your users on a bad id.

Binding by a non-id column is one line. Override the route key on the model:

// app/Models/User.php
public function getRouteKeyName(): string
{
    return 'uuid';
}

...or scope it to a single route with a binding field:

Route::get('/users/{user:email}', function (App\Models\User $user) {
    // resolves on email, not id
});

Nested resources need scoped bindings so the child is looked up inside the parent. Without scoping, /users/5/posts/99 would happily return post 99 even if it belongs to user 3:

Route::get('/users/{user}/posts/{post}', function (App\Models\User $user, App\Models\Post $post) {
    return $post;
})->scopedBindings();

With scopedBindings(), the post is queried with a WHERE user_id = {user} constraint. Security through URL structure — a user cannot enumerate another user's posts by guessing ids.

Optional parameters use a ? and a default in the handler:

Route::get('/tags/{tag?}', function (string $tag = 'all') {
    return view('tags.index', compact('tag'));
});

And you can constrain what a parameter accepts, which prevents needless database queries on garbage input:

Route::get('/orders/{order}/invoices/{invoice}', ...)
    ->whereNumber('order')
    ->whereAlphaNumeric('invoice');
// or a regex: ->where(['order' => '[0-9]+'])

The where* methods run before any handler or binding executes — a non-numeric {order} never reaches Eloquent, it falls through to a 404 immediately.

Binding also interacts with middleware ordering. The auth middleware redirects unauthenticated users to the login page on web routes, and it runs before the model is resolved — so an anonymous visitor never triggers a database lookup for a record they cannot see. This ordering matters for performance: on a public site with heavy traffic, expensive bindings stay behind the auth gate instead of hammering the database with queries for every stray hit.

Customizing a binding miss is a common follow-up once the defaults stop fitting. Returning JSON instead of the 404 page, for example, belongs in the withExceptions block of bootstrap/app.php:

use Symfony\Component\HttpKernel\Exception\NotFoundHttpException;

->withExceptions(function (Exceptions $exceptions) {
    $exceptions->render(function (NotFoundHttpException $e, Request $request) {
        if ($request->is('api/*') || $request->wantsJson()) {
            return response()->json(['message' => 'Record not found.'], 404);
        }
    });
})

The same hook catches binding failures and validation failures alike, because both surface as HttpExceptions the handler can inspect. When you need tighter control over a single model — say, a slug that must also be active — override resolveRouteBinding on the model itself and add the constraint there, keeping the check in one place instead of repeating it in every controller method.

Finally, watch for a subtle collision: a route parameter name must match the controller's argument name, or the injection silently fails. Route::get('/orders/{order}', [OrderController::class, 'show']) paired with a method signature function show(Order $id) will not bind — Laravel matches parameters to arguments by name, so {order} needs an $order argument. The mismatch fails silently rather than loudly: binding still resolves {order} into the order parameter, while the container builds a fresh, empty Order for $id — so the method receives a blank model instead of the row the URL identified, and the page renders empty fields instead of a 404.

A "resource" in REST terms is a noun with standard operations: list, create, store, show, edit, update, delete. Writing those seven routes by hand for every model is repetitive, so Laravel generates them in one line:

Route::resource('orders', OrderController::class);

That single call registers seven routes across five verbs:

The Name column is the route's name — a stable handle you use to generate URLs. Instead of hardcoding '/orders/5' in a Blade template, you write route('orders.show', $order) and the URL is derived from the route definition. Rename the URI path next week and every link in the app keeps working. Never hardcode URIs in views; always use route() — it is the single habit that makes refactoring routes safe.

Generating the controller with the matching methods:

php artisan make:controller OrderController --resource
# or, tied to a model with type-hinted binding already wired:
php artisan make:controller OrderController --resource --model=Order

The --model flag writes method signatures like show(Order $order) so implicit binding works out of the box — the boilerplate you would have typed by hand is already there.

You rarely want all seven routes. Trim with only or except:

Route::resource('orders', OrderController::class)
    ->only(['index', 'show', 'store']);

Route::resource('users', UserController::class)
    ->except(['edit', 'create']);   // a JSON API never needs form pages

Sub-resources and nesting use the ->parameters() or shallow form; a common shape is a nested resource where the child belongs to the parent:

Route::apiResource('users.posts', PostController::class);
// registers /users/{user}/posts/{post} with model binding on both

apiResource is resource minus the create and edit HTML routes — the right default for JSON endpoints.

Finally, group variations that keep related routes DRY:

Route::prefix('admin')->middleware('auth')->group(function () {
    Route::resource('orders', AdminOrderController::class);
    Route::get('/dashboard', [AdminDashboard::class, 'index'])->name('admin.dashboard');
});

Every route inside gets /admin prepended and the auth middleware applied. Check the result with php artisan route:list --path=admin — the names, URIs, and middleware all appear exactly as they will run.

Resource routes compose with named-route URL generation in a pattern worth memorizing: forms post to route('orders.store'), edit pages link to route('orders.update', $order) with @method('PUT'), and delete buttons submit to route('orders.destroy', $order) with @method('DELETE'). Browsers only send GET and POST natively, so the PUT and DELETE verbs are method-spoofed through a hidden _method field — you will build exactly this in the Blade topic. Until then, the mental model is: the route table speaks full REST, HTML forms speak GET and POST, and Laravel bridges the gap in between.

Two quality-of-life flags round out route:list. With the verbose flag -v you see the middleware stack applied to each route, which is the fastest way to confirm whether auth, throttle, or a custom group actually wraps your endpoint. And php artisan route:list --except-vendor strips package-registered routes so only your application's routes remain — useful when a dozen Horizon or Telescope routes crowd the output and you are hunting for one line of your own. Route names also double in artisan commands and redirects: return to(route('orders.show', $order)) after a successful store action keeps the post-redirect-get flow clean, and since the name resolves the current URI pattern, refactoring the path later never breaks the redirect.
Now that URLs reach handlers and models, the handlers need something to return: HTML from Blade templates, which is where escaping and layouts come in — see Blade Templates and Layouts.