What is the purpose of the "request" and "Response" objects of a web framework?

Question

Many frameworks that are based on routes use two objects at the time it executes the action corresponding to the route.

See an example on Slim:

$app->get('/hello/{name}', function (Request $request, Response $response, array $args) {
    $name = $args['name'];
    $response->getBody()->write("Hello, $name");

    return $response;
});

Another example in Silex:

$app->post('/feedback', function (Request $request) {
    $message = $request->get('message');
    mail('[email protected]', '[YourSite] Feedback', $message);

    return new Response('Thank you for your feedback!', 201);
});

Notice that objects are $request and $response. However, I still can’t enter what purpose they beyond the $request allow the manipulation of URI parameters itself. Therefore, I would like to clarify my doubts.

Doubts

• What is the purpose of objects $request and $response overall?
• What they represent in an application request?

Answer 1

I’ve had the opportunity to build some frameworks in languages like PHP and Python, as well as I’ve looked at how their source code works.

Basically, we can understand that the idea of frameworks is to abstract everything. And that’s no different with the request and the answer.

Every request made by a web client goes through the request and response step. And that’s the idea behind Silex, Slim and other frameworks.

Most frameworks used the class Request to represent the client’s incoming request. It may be that this varies between an object coming from a method or Factory parameter, but in the end the purpose is always to represent the client’s request.

In it, there should be important information for your backend to work, such as:

• Query string or payload parameters.
• Type of content requested, via Content-Type or Accept.
• Requisition and related methods.

This information, of course, does not depend on the framework. It is available in PHP, for example, in the variable $_SERVER with values prefixed by HTTP_.

In turn, the class Response greatly facilitates the abstraction of the response sent to the browser. It may seem simple, but when you think of a framework structure, you need to structure very well what is sent to the client. An example of this is the fact that the browser output cannot be defined before the headers. In this case, with the framework you could, for example, call the definition of the headers after the definition of what the output will be, because internally, the framework will stack the answer and organize how everything will be threaded to the browser.

Also, the idea of having a response class is to be able to "shorten" as much as possible the amount of code you will enter.

For example, a framework could have the method $response->json(), interactly transforming the output data into the format JSON and defining the header necessary for the browser to understand its answer in this format.

It all comes down to abstraction, as quoted by Guilherme Nascimento in the comments. It’s nothing you can no longer do with "pure PHP".

In my view, there are advantages and disadvantages, but these are things that you automatically take responsibility for accepting or not using a framework.

Commenting on some points of the question

Many frameworks that are based on routes use two objects at the time it executes the action corresponding to the route.

This is because basically the entire request cycle is based on a requisition and a reply. The two parameters represent the abstraction of each one of them, being able to have tools that facilitate access to some things.

For example, pure PHP, to decide whether to respond with JSON to the client if it requests it by header Accept, you would have to check if the value application/json is present in the variable $SERVER['HTTP_ACCEPT']. On the Laravel Framework, you could just call $request->isJson() or $request->wantsJson().

If you want to go further in the examples, we can also comment on the case of Silex (a penalty that has been deprecated), which uses the class Response to represent a response.

By default, this class Response Silex responds with the value passed as a string in the first parameter, and it is possible to define request status and extra headers (something that some beginners might have difficulty doing easily). Not to mention that there are classes that can be derived from Response, as JsonResponse, that would aim to return the answer already formatted for the client (I’ve commented this previously above).

These abstractions aim to create common operations and group them, as a way to facilitate the life of the programmer - there are those who disagree :).

PSR-7

If you’re curious, you can take a look at PSR-7. The idea seems to be geared towards giving library developers a head start on how to create abstractions from the requisition steps.