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.
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 ...