The idea here was to zoom in on a very specific question: how does application state relate to the URL? Not the whole universe of state in an app, just the part where the URL has a role in carrying, pointing to, or ignoring state entirely.
When the server handles a request, it combines state from different sources: the URL, cookies, headers, and whatever state it keeps internally on its side. On the client, there can also be local UI state, but that never leaves the client unless explicitly sent. So the table is really about the URL’s role among those sources, not about state everywhere.
After thinking through the possibilities, it turns out there are only three patterns for how URLs can participate:
- The URL contains some of the state directly
(for example filters, pagination, search parameters) - The URL contains a token that points to state stored elsewhere on the server
(often called “deep linking” in Datastar conversations) - The URL contains no state at all
(the state is fully external to the URL and comes from server-side memory, cookies, headers, or purely client-side logic)
That’s it. These three cases cover every way URLs and state can relate.
Regarding user identification: I initially wondered if it should be part of the model, but in the end it’s just one example of state, nothing more. Depending on which category you’re in, that piece of state might come from the URL, from cookies, or not be in the request at all. It didn’t deserve its own row.
And as a final note, this table only looks at state in relation to URLs. There’s a broader discussion to have about how state flows through other mediums (cookies, headers, local storage, server memory, SSE streams) and how these different channels combine to form the full picture. But this was my attempt to cleanly map just the URL part of the story.
| Category | Role of the URL | Where the Relevant State Actually Lives | Visibility & Stability | Example | When to Use |
|---|---|---|---|---|---|
| 1. State in the URL | The URL directly encodes the relevant state (fully or partially) | State is reconstructed from URL + optional cookies/headers | Shareable / stable / cacheable | /products?page=2&tag=rust |
When state represents a public, durable resource representation (filters, pagination, sorting) |
| 2. URL as Indirection | The URL contains a token pointing to state stored elsewhere | State lives in backend memory/DB/session, referenced by the token | Private / controlled / ephemeral | /view?state=8f3a9b → backend resolves token to view state |
When state is personalized, ephemeral, permissioned, or too brittle to expose directly in URL params |
| 3. No State in the URL | The URL carries no state information; it only names an endpoint/resource | State lives entirely outside URL: server memory, client memory, cookies, headers, or any mix | Internal / ephemeral / non-shareable via URL | /game → server pushes updates via SSE; or /editor → local-only UI state |
When state is realtime, transient, purely client-side, purely server-authoritative, or intentionally not URL-driven |