Universal “Soldier” in PHP

Request & Input: How Data Enters Controllers (Symfony, Laravel, Drupal)

After controllers and Dependency Injection, we reach the next universal concept in every PHP framework:

👉 How does user input get into your code?

Query params, POST data, headers, cookies, files — everything starts with HTTP Request.

Good news again:

All modern PHP frameworks handle input the same way.

Once you understand this layer, switching frameworks becomes mechanical, not stressful.

The One Truth About Requests

No matter which framework you use, this is always true:

HTTP Request
   ↓
Request object
   ↓
Controller

And in most cases:

• Laravel’s Request extends Symfony Request
• Drupal uses Symfony Request directly
• Symfony defines the standard

📌 Learn Symfony Request → understand all of them.

Universal Rule #3

Never read from $_GET, $_POST, $_FILES directly. Ever.

Frameworks exist to:

• normalize input
• secure access
• make testing possible

1. Symfony — the Pure Request Model

Symfony exposes the Request explicitly and honestly.

Controller with Request

use Symfony\Component\HttpFoundation\Request;
use Symfony\Component\HttpFoundation\Response;

class ProductController
{
    public function show(Request $request): Response
    {
        $id = $request->query->get('id');
        return new Response("Product ID: $id");
    }
}

Request structure (important!)

$request->query      // $_GET
$request->request    // $_POST
$request->headers
$request->cookies
$request->files
$request->server

Route parameters

#[Route('/product/{id}', name: 'product_show')]
public function show(int $id): Response
{
    return new Response("Product ID: $id");
}

📌 Symfony automatically maps route parameters to method arguments.

2. Laravel — Same Request, Friendlier API

Laravel makes input access look simpler, but nothing fundamentally changes.

Controller with Request

use Illuminate\Http\Request;

class ProductController extends Controller
{
    public function show(Request $request)
    {
        $id = $request->query('id');
        return "Product ID: $id";
    }
}

POST input

$name = $request->input('name');

Route parameters

Route::get('/product/{id}', function ($id) {
    return "Product ID: $id";
});

or

public function show(int $id)
{
    return "Product ID: $id";
}

📌 Laravel’s Request is Symfony Request + helper methods.

3. Drupal — Explicit but Identical

Drupal does not reinvent Request handling — it relies on Symfony.

Controller with Request

use Symfony\Component\HttpFoundation\Request;
use Symfony\Component\HttpFoundation\Response;

class ProductController
{
    public function show(Request $request): Response
    {
        $id = $request->query->get('id');
        return new Response("Product ID: $id");
    }
}

Route parameters (YAML)

mymodule.product:
  path: '/product/{id}'
  defaults:
    _controller: '\Drupal\mymodule\Controller\ProductController::show'
  requirements:
    _permission: 'access content'

Accessing route params via arguments

public function show(int $id): Response
{
    return new Response("Product ID: $id");
}

📌 Drupal passes route parameters exactly like Symfony.

Comparison Table: Input Access

The Universal Pattern

No matter the framework, aim for this:

public function handle(Request $request): Response
{
    $value = $request->get('key');
    // logic
}

Or even better:

public function handle(int $id, Request $request): Response
{
    // route params + request object
}

Common Beginner Mistakes

❌ Using superglobals:

$_GET['id'];
$_POST['name'];

❌ Pulling Request from globals:

\Drupal::request();
request();

✔️ Correct:

public function __construct(Request $request)

or

public function method(Request $request)

Why This Matters

Once you master Request handling:

• validation becomes trivial
• security improves automatically
• tests become easy
• framework switching becomes boring (in a good way)

Conclusion

• There is one Request model
• Symfony defines it
• Laravel simplifies it
• Drupal enforces it

Different syntax — same mental model.

You are no longer “learning frameworks”.
You are reusing architecture.