What’s actually slowing this PC down?

Pick the symptom - the matching free tool is one click away.

Special offer. See more information about Outbyte and uninstall instructions. Please review EULA and Privacy policy.

PHP exposes incoming HTTP data through separate superglobals such as $_GET, $_POST, $_FILES, $_COOKIE and $_SERVER. A Request object gives an application a more consistent, object-oriented way to access those sources. Use the request API that fits your framework: Symfony HttpFoundation works on its own or within Symfony, Laravel provides its own Request class, and PSR-7 offers interfaces for interoperability. None of these approaches makes user input trustworthy by itself.

What is a Request object in PHP?

A Request object represents information about an incoming HTTP request, such as its query parameters, submitted form data, uploaded files, cookies, headers and server details. Instead of reaching directly into PHP’s global variables throughout an application, code can use an object API to access the relevant request data.

PHP itself provides separate superglobals for these sources. For example, $_GET contains query-string values, $_POST contains form values handled through PHP’s POST mechanism, $_FILES describes uploaded files, and $_SERVER exposes server and request-environment values. A framework or library can organize access to them, but the underlying sources remain distinct.

Why use a Request object instead of superglobals?

Direct superglobal access can be adequate in a small, framework-free application. A Request object is useful when you want a consistent API, clearer separation between kinds of input, or components that can receive a request explicitly rather than reading global state. An interface-based request can also help middleware and libraries interoperate across frameworks.

Special offer. See more information about Outbyte and uninstall instructions. Please review EULA and Privacy policy.

Do not use $_REQUEST as a shortcut for all incoming data without considering its behavior: PHP documents that it combines GET, POST and COOKIE input according to configuration. Its values can be supplied or modified by remote users. Keep sources distinct where that difference matters, and validate and authorize values for the operation you are performing. A wrapper is an access interface, not a security check. PHP Manual: $_REQUEST

Choose the request API that fits your application

Approach Use it when Consideration
PHP superglobals The application is small, framework-free, and direct access suits its structure. Keep query, form, file, cookie and server data distinct; treat values as untrusted. PHP Manual
Symfony HttpFoundation Request You want an object-oriented request API in Symfony or as a standalone component. Use the appropriate bag for each data source and verify method behavior against the installed version. Symfony HttpFoundation documentation
Laravel IlluminateHttpRequest The application already uses Laravel and its request helpers. Laravel’s class extends Symfony HttpFoundation’s Request; use the documented bridge route if code needs PSR-7. Laravel request documentation
PSR-7 ServerRequestInterface A library or middleware needs a shared HTTP-message interface, or consumers should depend on an interface rather than a framework class. PSR-7 defines interfaces, not one concrete request object; an implementation or factory and possibly adapters are still needed. PHP-FIG PSR-7

Using Symfony HttpFoundation

HttpFoundation is a standalone Symfony component, so it can be added to a PHP application without adopting the full Symfony framework. The Symfony documentation shows installing it with Composer and creating a request from PHP’s current globals. Symfony HttpFoundation documentation

composer require symfony/http-foundation

After Composer’s autoloader is available, create the request at the application’s entry point:

require_once __DIR__ . '/vendor/autoload.php';

use SymfonyComponentHttpFoundationRequest;

$request = Request::createFromGlobals();

Symfony groups request data into named bags. The names make the source explicit:

Special offer. See more information about Outbyte and uninstall instructions. Please review EULA and Privacy policy.
Request bag PHP source or purpose
query Query parameters from $_GET
request Form/request parameters corresponding to $_POST
files Uploaded-file data corresponding to $_FILES
cookies Cookie values corresponding to $_COOKIE
server Server values corresponding to $_SERVER
headers HTTP headers
attributes Application data attached to the request; there is no corresponding PHP superglobal

For example, read a query parameter from the query bag rather than treating it as form data:

$page = $request->query->get('page');

Symfony’s current documentation also describes getPayload() for payload data that may arrive as form input or a JSON string. It provides access to payload data; it does not validate, sanitize or authorize that data. Check the documentation for the version installed in your application before relying on version-specific methods.

Using Laravel’s Request class

In a Laravel application, the usual choice is IlluminateHttpRequest. Laravel documents it as an object-oriented way to work with the current request, including input, cookies and uploaded files. The class extends SymfonyComponentHttpFoundationRequest, but application code should generally use the Laravel API expected by the application. Laravel request documentation

Laravel also documents a conversion path for code that must consume a PSR-7 request: use the Symfony HTTP Message Bridge and a PSR-7 implementation. That conversion requires the relevant dependencies; PSR-7 support does not mean Laravel’s own Request class is itself the PSR-7 interface. Consult the Laravel documentation that matches your installed version for the current setup details. Laravel request documentation

Special offer. See more information about Outbyte and uninstall instructions. Please review EULA and Privacy policy.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.Support on Ko-Fi

When PSR-7 is the right fit

PSR-7 is a PHP-FIG standard defining interfaces and semantics for HTTP messages, including server-side requests. A server request can represent server parameters, query parameters, a parsed body, uploaded files, cookies and derived attributes. Depending on an interface can reduce a component’s coupling to one framework or direct access to superglobals. PHP-FIG PSR-7

PSR-7 describes a contract, not a built-in PHP class that you can instantiate on its own. Your application needs an implementation or factory to create request objects, and an adapter may be needed when passing requests between systems with different APIs. PSR-7 message objects follow an immutable pattern: methods that change message properties return an updated instance rather than modifying the original. The body is a stream, however, and the stream’s internal state can change as it is read or written.

Handle body data, uploads and trust deliberately

  • Keep query and body input distinct. A query parameter and a submitted body field may share a name but have different meanings. Read from the source your operation expects.
  • Account for body format. Form input and JSON payloads may be exposed differently by an API. Use the framework’s documented parsing facilities for the installed version, and do not assume a convenience accessor performs validation.
  • Treat uploaded files as a separate input type. Use the request API’s file representation and follow the framework’s upload-handling guidance rather than treating file metadata as an ordinary string parameter.
  • Validate and authorize at the application boundary. Request objects describe incoming data; application rules determine whether that data is well-formed and whether the current user may act on it.

How to decide

  1. Start with the framework already in use. Use Laravel’s Request API in Laravel, or Symfony HttpFoundation in Symfony, unless an integration requirement calls for another contract.
  2. Choose the data boundaries you need. If query values, form fields, JSON payloads, uploads and cookies must remain clearly separated, prefer an API that exposes those sources explicitly.
  3. Check integration requirements. When middleware or reusable libraries need to work across frameworks, determine whether they accept PSR-7 interfaces and what implementation or adapter your stack supplies.
  4. Check the installed versions. Request helpers and payload behavior are version-dependent; use documentation for the PHP and framework versions actually deployed.
  5. Pass request data into application code intentionally. Explicitly providing a request or the needed values makes dependencies clearer than having unrelated code reach into global state.

Common mistakes to avoid

  • Assuming a Request object makes input safe. It organizes access; it does not establish trust.
  • Using a merged input source when precedence matters. Prefer the query, body, cookie or file source that matches the task instead of relying on an ambiguous combined value.
  • Assuming PSR-7 is a concrete framework class. It is an interface standard; a compatible implementation is required.
  • Expecting immutable messages to freeze a body stream. Message methods return new message instances, while the stream can have mutable read/write position or state.
  • Assuming framework APIs are interchangeable. Symfony, Laravel and PSR-7 have different APIs and integration paths; verify behavior against your installed versions.

Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.