What Is MVC?

In MVC, you have three primary concepts:

model

Represents an individual database table (or a record from that table)—think “Company” or “Dog.”

view

Represents the template that outputs your data to the end user—think “the login page template with this given set of HTML and CSS and JavaScript.”

controller

Like a traffic cop, takes HTTP requests from the browser, gets the right data out of the database and other storage mechanisms, validates user input, and eventually sends a response back to the user.

In Figure 3-1, you can see that the end user will first interact with the controller by sending an HTTP request using their browser. The controller, in response to that request, may write data to and/or pull data from the model (database). The controller will then likely send data to a view, and then the view will be returned to the end user to display in their browser.

Figure 3-1. A basic illustration of MVC

We’ll cover some use cases for Laravel that don’t fit this relatively simplistic way of looking at application architecture, so don’t get hung up on MVC, but this will at least get you ready to approach the rest of this chapter as we talk about views and controllers.

The HTTP Verbs

The most common HTTP verbs are GET and POST, followed by PUT and DELETE. There are also HEAD, OPTIONS, and PATCH, and two others that are pretty much never used in normal web development, TRACE and CONNECT.

Here’s a quick rundown:

GET

Request a resource (or a list of resources).

HEAD

Ask for a headers-only version of the GET response.

POST

Create a resource.

PUT

Overwrite a resource.

PATCH

Modify a resource.

DELETE

Delete a resource.

OPTIONS

Ask the server which verbs are allowed at this URL.

Table 3-1 shows the actions available on a resource controller (more on these in “Resource Controllers”). Each action expects you to call a specific URL pattern using a specific verb, so you can get a sense of what each verb is used for.

What Is REST?

We’ll cover REST in greater detail in “The Basics of REST-Like JSON APIs”, but as a brief introduction, it’s an architectural style for building APIs. When we talk about REST in this book, we’ll mainly be referencing a few characteristics, such as:

• Being structured around one primary resource at a time (e.g., tasks)

• Consisting of interactions with predictable URL structures using HTTP verbs (as seen in Table 3-1)

• Returning JSON and often being requested with JSON

There’s more to it, but usually “RESTful” as it’ll be used in this book will mean “patterned after these URL-based structures so we can make predictable calls like GET /tasks/14/edit for the edit page.” This is relevant (even when not building APIs) because Laravel’s routing structures are based around a REST-like structure, as you can see in Table 3-1.

REST-based APIs follow mainly this same structure, except they don’t have a create route or an edit route, since APIs just represent actions, not pages that prep for the actions.

Route Verbs

You might’ve noticed that we’ve been using Route::get() in our route definitions. This means we’re telling Laravel to only match for these routes when the HTTP request uses the GET action. But what if it’s a form POST, or maybe some JavaScript sending PUT or DELETE requests? There are a few other options for methods to call on a route definition, as illustrated in Example 3-3.

Route::get('/', function () {
    return 'Hello, World!';
});

Route::post('/', function () {
    // Handle someone sending a POST request to this route
});

Route::put('/', function () {
    // Handle someone sending a PUT request to this route
});

Route::delete('/', function () {
    // Handle someone sending a DELETE request to this route
});

Route::any('/', function () {
    // Handle any verb request to this route
});

Route::match(['get', 'post'], '/', function () {
    // Handle GET or POST requests to this route
});

Route Handling

As you’ve probably guessed, passing a closure to the route definition is not the only way to teach it how to resolve a route. Closures are quick and simple, but the larger your application gets, the clumsier it becomes to put all of your routing logic in one file. Additionally, applications using route closures can’t take advantage of Laravel’s route caching (more on that later), which can shave up to hundreds of milliseconds off of each request.

The other common option is to pass a controller name and method as a string in place of the closure, as in Example 3-4.

Route::get('/', 'WelcomeController@index');

This is telling Laravel to pass requests to that path to the index() method of the AppHttpControllersWelcomeController controller. This method will be passed the same parameters and treated the same way as a closure you might’ve alternatively put in its place.

Route Parameters

If the route you’re defining has parameters—segments in the URL structure that are variable—it’s simple to define them in your route and pass them to your closure (see Example 3-5).

Route::get('users/{id}/friends', function ($id) {
    //
});

You can also make your route parameters optional by including a question mark (?) after the parameter name, as illustrated in Example 3-6. In this case, you should also provide a default value for the route’s corresponding variable.

Route::get('users/{id?}', function ($id = 'fallbackId') {
    //
});

And you can use regular expressions (regexes) to define that a route should only match if a parameter meets particular requirements, as in Example 3-7.

Route::get('users/{id}', function ($id) {
    //
})->where('id', '[0-9]+');

Route::get('users/{username}', function ($username) {
    //
})->where('username', '[A-Za-z]+');

Route::get('posts/{id}/{slug}', function ($id, $slug) {
    //
})->where(['id' => '[0-9]+', 'slug' => '[A-Za-z]+']);

As you’ve probably guessed, if you visit a path that matches a route string but the regex doesn’t match the parameter, it won’t be matched. Since routes are matched top to bottom, users/abc would skip the first closure in Example 3-7, but it would be matched by the second closure, so it would get routed there. On the other hand, posts/abc/123 wouldn’t match any of the closures, so it would return a 404 (Not Found) error.

Route Names

The simplest way to refer to these routes elsewhere in your application is just by their path. There’s a url() global helper to simplify that linking in your views, if you need it; see Example 3-8 for an example. The helper will prefix your route with the full domain of your site.

<a href="<?php echo url('/'); ?>">
// Outputs <a href="http://myapp.com/">

However, Laravel also allows you to name each route, which enables you to refer to it without explicitly referencing the URL. This is helpful because it means you can give simple nicknames to complex routes, and also because linking them by name means you don’t have to rewrite your frontend links if the paths change (see Example 3-9).

// Defining a route with name() in routes/web.php:
Route::get('members/{id}', 'MemberController@show')->name('members.show');

// Linking the route in a view using the route() helper:
<a href="<?php echo route('members.show', ['id' => 14]); ?>">

This example illustrates a few new concepts. First, we’re using fluent route definition to add the name, by chaining the name() method after the get() method. This method allows us to name the route, giving it a short alias to make it easier to reference elsewhere.

Route::get('members/{id}', [
    'as' => 'members.show',
    'uses' => 'MemberController@show',
]);

In our example, we’ve named this route members.show; resourcePlural.action is a common convention within Laravel for route and view names.

This example also introduced the route() helper. Just like url(), it’s intended to be used in views to simplify linking to a named route. If the route has no parameters, you can simply pass the route name (route('members.index')) and receive a route string (http://myapp.com/members). If it has parameters, pass them in as an array as the second parameter like we did in Example 3-9.

In general, I recommend using route names instead of paths to refer to your routes, and therefore using the route() helper instead of the url() helper. Sometimes it can get a bit clumsy—for example, if you’re working with multiple subdomains—but it provides an incredible level of flexibility to later change the application’s routing structure without major penalty.

Middleware

Probably the most common use for route groups is to apply middleware to a group of routes. You’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, this means users have to be logged in to the application to view the dashboard or the account page.

Route::middleware('auth')->group(function() {
    Route::get('dashboard', function () {
        return view('dashboard');
    });
    Route::get('account', function () {
        return view('account');
    });
});

Route::group(['middleware' => 'auth'], function () {
    Route::get('dashboard', function () {
        return view('dashboard');
    });
    Route::get('account', function () {
        return view('account');
    });
});

class DashboardController extends Controller
{
    public function __construct()
    {
        $this->middleware('auth');

        $this->middleware('admin-auth')
            ->only('editUsers');

        $this->middleware('team-member')
            ->except('editUsers');
    }
}

Route::middleware('auth:api', 'throttle:60,1')->group(function () {
    Route::get('/profile', function () {
        //
    });
});

Path Prefixes

If you have a group of routes that share a segment of their path—for example, if your site’s dashboard is prefixed with /dashboard—you can use route groups to simplify this structure (see Example 3-13).

Route::prefix('dashboard')->group(function () {
    Route::get('/', function () {
        // Handles the path /dashboard
    });
    Route::get('users', function () {
        // Handles the path /dashboard/users
    });
});

Note that each prefixed group also has a / route that represents the root of the prefix—in Example 3-13 that’s /dashboard.

Fallback Routes

In Laravel prior to 5.6, you could define a “fallback route” (which you need to define at the end of your routes file) to catch all unmatched paths:

Route::any('{anything}', 'CatchAllController')->where('anything', '*');

In Laravel 5.6+, you can use the Route::fallback() method instead:

Route::fallback(function () {
    //
});

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-14 shows how you can achieve this.

Route::domain('api.myapp.com')->group(function () {
    Route::get('/', function () {
        //
    });
});

Second, you might want to set part of the subdomain as a parameter, as illustrated in Example 3-15. 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::domain('{account}.myapp.com')->group(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 dashboard example, all of the dashboard routes’ controllers might be under a Dashboard namespace. By using the route group namespace prefix, as shown in Example 3-16, you can avoid long controller references in groups like "Dashboard/UserController@index" and "Dashboard/PurchaseController@index".

// AppHttpControllersUserController
Route::get('/', 'UserController@index');

Route::namespace('Dashboard')->group(function () {
    // AppHttpControllersDashboardPurchaseController
    Route::get('dashboard/purchases', 'PurchaseController@index');
});

Name Prefixes

The prefixes don’t stop there. It’s common that route names will reflect the inheritance chain of path elements, so users/comments/5 will be served by a route named users.comments.show. In this case, it’s common to use a route group around all of the routes that are beneath the users.comments resource.

Just like we can prefix URL segments and controller namespaces, we can also prefix strings to the route name. With route group name prefixes, we can define that every route within this group should have a given string prefixed to its name. In this context, we’re prefixing "users." to each route name, then "comments." (see Example 3-17).

Route::name('users.')->prefix('users')->group(function () {
    Route::name('comments.')->prefix('comments')->group(function () {
        Route::get('{id}', function () {

        })->name('show');
    });
});

Signing a Route

In order to build a signed URL to access a given route, the route must have a name:

Route::get('invitations/{invitation}/{answer}', 'InvitationController')
    ->name('invitations');

To generate a normal link to this route you would use the route() helper, as we’ve already covered, but you could also use the URL facade to do the same thing: URL::route('invitations', ['invitation' => 12345, 'answer' => 'yes']). To generate a signed link to this route, simply use the signedRoute() method instead. And if you want to generate a signed route with an expiration, use temporarySignedRoute():

// Generate a normal link
URL::route('invitations', ['invitation' => 12345, 'answer' => 'yes']);

// Generate a signed link
URL::signedRoute('invitations', ['invitation' => 12345, 'answer' => 'yes']);

// Generate an expiring (temporary) signed link
URL::temporarySignedRoute(
    'invitations',
    now()->addHours(4),
    ['invitation' => 12345, 'answer' => 'yes']
);

Modifying Routes to Allow Signed Links

Now that you’ve generated a link to your signed route, you need to protect against any unsigned access. The easiest option is to apply the signed middleware (which, if it’s not in your $routeMiddleware array in app/Http/Kernel.php, should be, backed by IlluminateRoutingMiddlewareValidateSignature):

Route::get('invitations/{invitation}/{answer}', 'InvitationController')
    ->name('invitations')
    ->middleware('signed');

If you’d prefer, you can manually validate using the hasValidSignature() method on the Request object instead of using the signed middleware:

class InvitationController
{
    public function __invoke(Invitation $invitation, $answer, Request $request)
    {
        if (! $request->hasValidSignature()) {
            abort(403);
        }

        //
    }
}

Returning Simple Routes Directly with Route::view()

Because it’s so common for a route to just return a view with no custom data, Laravel 5.5+ allows you to define a route as a “view” route without even passing the route definition a closure or a controller/method reference, as you can see in Example 3-20.

// Returns resources/views/welcome.blade.php
Route::view('/', 'welcome');

// Passing simple data to Route::view()
Route::view('/', 'welcome', ['User' => 'Michael']);

Using View Composers to Share Variables with Every View

Sometimes it can become a hassle to pass the same variables over and over. There may be a variable that you want accessible to every view in the site, or to a certain class of views or a certain included subview—for example, all views related to tasks, or the header partial.

It’s possible to share certain variables with every template or just certain templates, like in the following code:

view()->share('variableName', 'variableValue');

To learn more, check out “View Composers and Service Injection”.

Getting User Input

The second most common action to perform in a controller method is to take input from the user and act on it. That introduces a few new concepts, so let’s take a look at a bit of sample code and walk through the new pieces.

First, let’s bind our route; see Example 3-25.

// routes/web.php
Route::get('tasks/create', 'TaskController@create');
Route::post('tasks', 'TaskController@store');

Notice that we’re binding the GET action of tasks/create (which shows a form for creating a new task) and the POST action of tasks/ (which is where our form will POST to when we’re creating a new task). We can assume the create() method in our controller just shows a form, so let’s look at the store() method in Example 3-26.

// TaskController.php
...
public function store()
{
    Task::create(request()->only(['title', 'description']));

    return redirect('tasks');
}

This example makes use of Eloquent models and the redirect() functionality, and we’ll talk about them more later, but for now let’s talk quickly about how we’re getting our data here.

We’re using the request() helper to represent the HTTP request (more on that later) and using its only() method to pull just the title and description fields the user submitted.

We’re then passing that data into the create() method of our Task model, which creates a new instance of the Task with title set to the passed-in title and description set to the passed-in description. Finally, we redirect back to the page that shows all tasks.

There are a few layers of abstraction at work here, which we’ll cover in a second, but know that the data coming from the only() method comes from the same pool of data all common methods used on the Request object draw from, including all() and get(). The set of data each of these methods is pulling from represents all user-provided data, whether from query parameters or POST values. So, our user filled out two fields on the “add task” page: “title” and “description.”

To break down the abstraction a bit, request()->only() takes an associative array of input names and returns them:

request()->only(['title', 'description']);
// returns:
[
    'title' => 'Whatever title the user typed on the previous page',
    'description' => 'Whatever description the user typed on the previous page',
]

And Task::create() takes an associative array and creates a new task from it:

Task::create([
    'title' => 'Buy milk',
    'description' => 'Remember to check the expiration date this time, Norbert!',
]);

Combining them together creates a task with just the user-provided “title” and “description” fields.

Injecting Dependencies into Controllers

Laravel’s facades and global helpers present a simple interface to the most useful classes in Laravel’s codebase. You can get information about the current request and user input, the session, caches, and much more.

But if you prefer to inject your dependencies, or if you want to use a service that doesn’t have a facade or a helper, you’ll need to find some way to bring instances of these classes into your controller.

This is our first exposure to Laravel’s service container. For now, if this is unfamiliar, you can think about it as a little bit of Laravel magic; or, if you want to know more about how it’s actually functioning, you can skip ahead to Chapter 11.

All controller methods (including the constructors) are resolved out of Laravel’s container, which means anything you typehint that the container knows how to resolve will be automatically injected.

public function __construct(Logger $logger) {}

As a nice example, what if you’d prefer having an instance of the Request object instead of using the global helper? Just typehint IlluminateHttpRequest in your method parameters, like in Example 3-27.

// TaskController.php
...
public function store(IlluminateHttpRequest $request)
{
    Task::create($request->only(['title', 'description']));

    return redirect('tasks');
}

So, you’ve defined a parameter that must be passed into the store() method. And since you typehinted it, and since Laravel knows how to resolve that class name, you’re going to have the Request object ready for you to use in your method with no work on your part. No explicit binding, no anything else—it’s just there as the $request variable.

And, as you can tell from comparing Example 3-26 and Example 3-27, the request() helper and the Request object behave exactly the same.

Resource Controllers

Sometimes naming the methods in your controllers can be the hardest part of writing a controller. Thankfully, Laravel has some conventions for all of the routes of a traditional REST/CRUD controller (called a “resource controller” in Laravel); additionally, it comes with a generator out of the box and a convenience route definition that allows you to bind an entire resource controller at once.

To see the methods that Laravel expects for a resource controller, let’s generate a new controller from the command line:

php artisan make:controller MySampleResourceController --resource

Now open app/Http/Controllers/MySampleResourceController.php. You’ll see it comes prefilled with quite a few methods. Let’s walk over what each represents. We’ll use a Task as an example.

Binding a resource controller

So, we’ve seen that these are the conventional route names to use in Laravel, and also that it’s easy to generate a resource controller with methods for each of these default routes. Thankfully, you don’t have to generate routes for each of these controller methods by hand, if you don’t want to. There’s a trick for that, called resource controller binding. Take a look at Example 3-28.

Example 3-28. Resource controller binding

// routes/web.php
Route::resource('tasks', 'TaskController');

This will automatically bind all of the routes listed in Table 3-1 for this resource to the appropriate method names on the specified controller. It’ll also name these routes appropriately; for example, the index() method on the tasks resource controller will be named tasks.index.

artisan route:list

If you ever find yourself in a situation where you’re wondering what routes your current application has available, there’s a tool for that: from the command line, run php artisan route:list and you’ll get a listing of all of the available routes (see Figure 3-2).

Figure 3-2. artisan route:list

API Resource Controllers

When you’re working with RESTful APIs, the list of potential actions on a resource is not the same as it is with an HTML resource controller. For example, you can send a POST request to an API to create a resource, but you can’t really “show a create form” in an API.

Laravel 5.6 introduced a new way to generate an API resource controller, which has the same structure as a resource controller except it excludes the create and edit actions. We can generate API resource controllers by passing the --api flag when creating a controller:

php artisan make:controller MySampleResourceController --api

// routes/web.php
Route::apiResource('tasks', 'TaskController');

Single Action Controllers

There will be times in your applications when a controller should only service a single route. You may find yourself wondering how to name the controller method for that route. Thankfully, you can point a single route at a single controller without concerning yourself with naming the one method.

As you may already know, the __invoke() method is a PHP magic method that allows you to “invoke” an instance of a class, treating it like a function and calling it. This is the tool Laravel’s single action controllers use to allow you to point a route to a single controller, as you can see in Example 3-30.

// AppHttpControllersUpdateUserAvatar.php
public function __invoke(User $user)
{
    // Update the user's avatar image
}

// routes/web.php
Route::post('users/{user}/update-avatar', 'UpdateUserAvatar');

Implicit Route Model Binding

The simplest way to use route model binding is to name your route parameter something unique to that model (e.g., name it $conference instead of $id), then typehint that parameter in the closure/controller method and use the same variable name there. It’s easier to show than to describe, so take a look at Example 3-32.

Route::get('conferences/{conference}', function (Conference $conference) {
    return view('conferences.show')->with('conference', $conference);
});

Because the route parameter ({conference}) is the same as the method parameter ($conference), and the method parameter is typehinted with a Conference model (Conference $conference), Laravel sees this as a route model binding. Every time this route is visited, the application will assume that whatever is passed into the URL in place of {conference} is an ID that should be used to look up a Conference, and then that resulting model instance will be passed in to your closure or controller method.

public function getRouteKeyName()
{
    return 'slug';
}

Implicit route model binding was added in Laravel 5.2, so you won’t have access to it in 5.1.

Custom Route Model Binding

To manually configure route model bindings, add a line like the one in Example 3-33 to the boot() method in AppProvidersRouteServiceProvider.

    public function boot()
    {
        // Just allows the parent's boot() method to still run
        parent::boot();

        // Perform the binding
        Route::model('event', Conference::class);
    }

You’ve now specified that whenever a route has a parameter in its definition named {event}, as demonstrated in Example 3-34, the route resolver will return an instance of the Conference class with the ID of that URL parameter.

Route::get('events/{event}', function (Conference $event) {
    return view('events.show')->with('event', $event);
});

HTTP Verbs in Laravel

As we’ve seen already, you can define which verbs a route will match in the route definition using Route::get(), Route::post(), Route::any(), or Route::match(). You can also match with Route::patch(), Route::put(), and Route::delete().

But how does one send a request other than GET with a web browser? First, the method attribute in an HTML form determines its HTTP verb: if your form has a method of "GET", it will submit via query parameters and a GET method; if the form has a method of "POST", it will submit via the post body and a POST method.

JavaScript frameworks make it easy to send other requests, like DELETE and PATCH. But if you find yourself needing to submit HTML forms in Laravel with verbs other than GET or POST, you’ll need to use form method spoofing, which means spoofing the HTTP method in an HTML form.

HTTP Method Spoofing in HTML Forms

To inform Laravel that the form you’re currently submitting should be treated as something other than a POST, add a hidden variable named _method with the value of either "PUT", "PATCH", or "DELETE", and Laravel will match and route that form submission as if it were actually a request with that verb.

The form in Example 3-35, since it’s passing Laravel the method of "DELETE", will match routes defined with Route::delete() but not those with Route::post().

<form action="/tasks/5" method="POST">
    <input type="hidden" name="_method" value="DELETE">
    <!-- or: -->
    @method('DELETE')
</form>

redirect()->to()

The method signature for the to() method for redirects looks like this:

function to($to = null, $status = 302, $headers = [], $secure = null)

$to is a valid internal path, $status is the HTTP status (defaulting to 302), $headers allows you to define which HTTP headers to send along with your redirect, and $secure allows you to override the default choice of http versus https (which is normally set based on your current request URL). Example 3-39 shows an example of its use.

Route::get('redirect', function () {
    return redirect()->to('home');

    // Or same, using the shortcut:

    return redirect('home');
});

redirect()->route()

The route() method is the same as the to() method, but rather than pointing to a particular path, it points to a particular route name (see Example 3-40).

Route::get('redirect', function () {
    return redirect()->route('conferences.index');
});

Note that, since some route names require parameters, its parameter order is a little different. route() has an optional second parameter for the route parameters:

function route($to = null, $parameters = [], $status = 302, $headers = [])

So, using it might look a little like Example 3-41.

Route::get('redirect', function () {
    return redirect()->route('conferences.show', ['conference' => 99]);
});

redirect()->back()

Because of some of the built-in conveniences of Laravel’s session implementation, your application will always have knowledge of what the user’s previously visited page was. That opens up the opportunity for a redirect()->back() redirect, which simply redirects the user to whatever page they came from. There’s also a global shortcut for this: back().

Other Redirect Methods

The redirect service provides other methods that are less commonly used, but still available:

home()

Redirects to a route named home.

refresh()

Redirects to the same page the user is currently on.

away()

Allows for redirecting to an external URL without the default URL validation.

secure()

Like to() with the secure parameter set to "true".

action()

Allows you to link to a controller and method in one of two ways: as a string (redirect()->action('MyController@myMethod')) or as a tuple (redirect()->action([MyController::class, 'myMethod'])).

guest()

Used internally by the authentification system (discussed in Chapter 9); when a user visits a route they’re not authenticated for, this captures the “intended” route and then redirects the user (usually to a login page).

intended()

Also used internally by the auth system; after a successful authentication, this grabs the “intended” URL stored by the guest() method and redirects the user there.

redirect()->with()

While it is structured similarly to the other methods you can call on redirect(), with() is different in that it doesn’t define where you’re redirecting to, but what data you’re passing along with the redirect. When you’re redirecting users to different pages, you often want to pass certain data along with them. You could manually flash the data to the session, but Laravel has some convenience methods to help you with that.

Most commonly, you can pass along either an array of keys and values or a single key and value using with(), like in Example 3-42. This saves your with() data to the session just for the next page load.

Route::get('redirect-with-key-value', function () {
    return redirect('dashboard')
        ->with('error', true);
});

Route::get('redirect-with-array', function () {
    return redirect('dashboard')
        ->with(['error' => true, 'message' => 'Whoops!']);
});

You can also use withInput(), as in Example 3-43, to redirect with the user’s form input flashed; this is most common in the case of a validation error, where you want to send the user back to the form they just came from.

Route::get('form', function () {
    return view('form');
});

Route::post('form', function () {
    return redirect('form')
        ->withInput()
        ->with(['error' => true, 'message' => 'Whoops!']);
});

The easiest way to get the flashed input that was passed with withInput() is using the old() helper, which can be used to get all old input (old()) or just the value for a particular key as shown in the following example, with the second parameter as the default if there is no old value). You’ll commonly see this in views, which allows this HTML to be used both on the “create” and the “edit” view for this form:

<input name="username" value="<?=
    old('username', 'Default username instructions here');
?>">

Speaking of validation, there is also a useful method for passing errors along with a redirect response: withErrors(). You can pass it any “provider” of errors, which may be an error string, an array of errors, or, most commonly, an instance of the Illuminate Validator, which we’ll cover in Chapter 10. Example 3-44 shows an example of its use.

Route::post('form', function (IlluminateHttpRequest $request) {
    $validator = Validator::make($request->all(), $this->validationRules);

    if ($validator->fails()) {
        return back()
            ->withErrors($validator)
            ->withInput();
    }
});

withErrors() automatically shares an $errors variable with the views of the page it’s redirecting to, for you to handle however you’d like.

response()->make()

If you want to create an HTTP response manually, just pass your data into the first parameter of response()->make(): for example, return response()->make(Hello, World!). Once again, the second parameter is the HTTP status code and the third is your headers.

response()->json() and ->jsonp()

To create a JSON-encoded HTTP response manually, pass your JSON-able content (arrays, collections, or whatever else) to the json() method: for example return response()->json(User::all()). It’s just like make(), except it +json_encode+s your content and sets the appropriate headers.

response()->download(), ->streamDownload(), and ->file()

To send a file for the end user to download, pass either an SplFileInfo instance or a string filename to download(), with an optional second parameter of the download filename: for example, return response()->download('file501751.pdf', 'myFile.pdf'), which would send a file that’s at file501751.pdf and rename it, as it’s sent, myFile.pdf.

To display the same file in the browser (if it’s a PDF or an image or something else the browser can handle), use response()->file() instead, which takes the same parameters as response->download().

If you want to make some content from an external service available as a download without having to write it directly to your server’s disk, you can stream the download using response()->streamDownload(). This method expects as parameters a closure that echoes a string, a filename, and optionally an array of headers; see Example 3-46.

return response()->streamDownload(function () {
    echo DocumentService::file('myFile')->getContent();
}, 'myFile.pdf');