Web Programming Fundamentals

PHP applications live inside the HTTP request-and-response cycle. Understanding that cycle makes routing, forms, authentication, APIs, caching, and debugging much easier.

The Request Cycle

The browser resolves the host. DNS returns the address of the web server or reverse proxy.
A connection is established. HTTPS adds TLS negotiation before HTTP data is exchanged.
The browser sends a request. The request includes a method, path, headers, and sometimes a body.
The web server invokes PHP. Apache, nginx with PHP-FPM, or another server passes the request to the application.
The application runs. It validates input, loads data, applies business rules, and produces a response.
The browser receives the response. It uses the status code, headers, and body to decide what to display or do next.

GET /customers/42 HTTP/1.1
Host: example.test
Accept: text/html
Cookie: session_id=abc123

HTTP Methods and Intent

Method	Typical purpose	Expected behavior
`GET`	Read a page or resource	Should not create, modify, or delete data.
`POST`	Create or submit an action	Usually has a request body and may change state.
`PUT`	Replace a resource	Common in APIs and generally idempotent.
`PATCH`	Partially update a resource	Changes only specified fields.
`DELETE`	Remove a resource	Should require authorization and CSRF protection in browser applications.

Do not use a GET link for destructive actions. Crawlers, browser prefetching, and accidental clicks can follow links. Use a state-changing method and verify authorization.

Status Codes Are Part of the Interface

Code	Use
`200 OK`	A normal successful response.
`201 Created`	A resource was created successfully.
`204 No Content`	The action succeeded and no body is needed.
`302 Found` / `303 See Other`	Redirect after an action, often following a successful form POST.
`400 Bad Request`	The request is malformed.
`401 Unauthorized`	Authentication is required or invalid.
`403 Forbidden`	The identity is known but lacks permission.
`404 Not Found`	The requested resource does not exist or should not be revealed.
`422 Unprocessable Content`	The request is structurally valid but fails validation.
`500 Internal Server Error`	An unexpected application failure occurred.

Headers, Content Types, and Cookies

Headers carry metadata about the request and response. Applications commonly inspect Accept, Content-Type, authorization headers, forwarding headers from a trusted reverse proxy, and caching headers.

<?php
declare(strict_types=1);

header('Content-Type: application/json; charset=utf-8');
header('Cache-Control: no-store');

http_response_code(200);
echo json_encode(
    ['status' => 'ok'],
    JSON_THROW_ON_ERROR
);

HTTP Is Stateless

Each request stands alone. Sessions create continuity by storing data on the server and associating it with a session identifier in a cookie. Authentication should never depend solely on hidden form fields or query-string values because the client controls them.

Know Which Data You Can Trust

Everything from $_GET, $_POST, cookies, JSON bodies, and uploaded files is untrusted.
Headers can be forged unless a trusted reverse proxy replaces or validates them.
Database values may still require escaping when rendered into HTML.
Authorization must be checked on every protected action, not only when the menu is displayed.
Validation answers “is this input acceptable?” while escaping answers “is this output safe in this context?”