GET vs POST vs REQUEST in PHP

PHP gives you three superglobals for reading request data, and picking the wrong one is a common source of subtle bugs — they read from different sources, not just different HTTP methods.

$_GET

// URL: /search?q=laravel
$query = $_GET['q']; // "laravel"

Reads values from the URL's query string only — regardless of the actual HTTP method used for the request. A POST request to a URL with a query string still populates $_GET from that query string.

$_POST

<form method="post" action="/submit">
    <input name="email">
</form>

$email = $_POST['email'];

Reads values from the request body of a POST request specifically — form fields submitted via method="post", or a POST body sent with Content-Type: application/x-www-form-urlencoded or multipart/form-data.

$_REQUEST — reads from GET, POST, and cookies combined

$value = $_REQUEST['q']; // could come from GET, POST, or a cookie

This is the actual problem with $_REQUEST: it merges $_GET, $_POST, and $_COOKIE (the exact merge order is configurable via request_order in php.ini), so you can't tell from the code alone where a given value actually came from. If a cookie and a POST field happen to share a name, which one wins depends on server configuration, not your code — a real source of hard-to-reproduce bugs.

The practical rule

Use $_GET or $_POST explicitly based on where you actually expect the data to come from. Avoid $_REQUEST in real application code — the ambiguity it introduces isn't worth whatever convenience it offers. In a Laravel app, this whole category of problem is handled by the unified Request object ($request->input('q')), which has its own explicit, documented precedence rules instead of PHP's configurable, less obvious one.