Laravel: Up and Running

Chapter 10. Requests and Responses

We’ve already covered the Illuminate Request object a bit—how you can typehint it in constructors to get an instance, and then use that to get information about the user’s input. In Chapter 3, for example, we saw how you can typehint it in constructors to get an instance, and in Chapter 6 we looked at how you can use it to get information about the user’s input.

In this chapter, we’ll learn more about what that Request object is, how it’s generated and what it represents, and what part it plays in your application’s lifecycle. We’ll also talk about the Response object and Laravel’s implementation of the middleware pattern.

Laravel’s Request Lifecycle

Every request coming into a Laravel application, whether generated by an HTTP request or a command-line interaction, is immediately converted into an Illuminate Request object, which then crosses many layers and ends up being parsed by the application itself. The application then generates an Illuminate Response object, which is sent back out across those layers and finally returned to the end user.

This request/response lifecycle is illustrated in Figure 10-1.

Let’s take a look at what it takes to make each of these steps happen, from the first line of code to the last.

Every Laravel application has some form of configuration set up at the web server level, in an .htaccess file or an Nginx configuration setting or something similar, that captures every web request regardless of URL and routes it ...