GET, POST, and REQUEST in PHP: What Is the Difference?

PHP's three superglobals for reading request data — $_GET, $_POST, and $_REQUEST — each pull from a different source, and understanding the difference matters for both correctness and a subtle security consideration.

$_GET: query string parameters

// URL: /search.php?query=laravel&page=2
echo $_GET['query']; // "laravel"
echo $_GET['page'];  // "2"

$_GET reads only from the URL's query string — data here is visible in the URL itself, can be bookmarked, and has a practical length limit imposed by browsers and servers, making it unsuitable for large payloads or sensitive data like a password.

$_POST: form body data

echo $_POST['username'];
echo $_POST['password'];

$_POST reads data sent in the HTTP request body, not the URL — this is why POST is the correct method for a login form or any form submitting sensitive or large data, since the values don't appear in the URL, browser history, or server access logs the way GET parameters do.

$_REQUEST: a combination of GET, POST, and cookies

// Works regardless of whether 'id' came from the query string or form body
$id = $_REQUEST['id'];

$_REQUEST merges $_GET, $_POST, and $_COOKIE into one array — this can seem convenient for code that shouldn't care which method delivered a given value, but it introduces a genuine ambiguity problem worth understanding before reaching for it.

The precedence problem with $_REQUEST

// If both a GET param and a POST field are named "action"...
$action = $_REQUEST['action']; // which one wins?

PHP's default configuration (controlled by the request_order directive in php.ini) determines which source takes precedence when the same key exists in more than one of GET, POST, or cookies — since this behavior is configuration-dependent rather than fixed, code relying on $_REQUEST can behave inconsistently across different server environments with different php.ini settings.

Why explicit $_GET or $_POST is generally the safer choice

Using $_GET or $_POST explicitly, rather than $_REQUEST, makes the code's intent unambiguous and immune to the precedence-configuration issue above — it's also a mild security consideration, since $_REQUEST including cookie data means a value an attacker could set via a cookie might unexpectedly satisfy a check intended only for a GET or POST parameter.

How this maps to Laravel's own Request object

$request->query('search');   // equivalent to $_GET
$request->input('name');     // checks POST body, then query string
$request->post('name');      // POST body specifically (rarely used directly)

Laravel's Request object abstracts over these same underlying superglobals — $request->input() behaves similarly to $_REQUEST in checking multiple sources, while $request->query() and route-based validation give the same explicit-source clarity that reaching for $_GET/$_POST directly provides in plain PHP.