The URL in the address bar is special because it can leave the application. It can be copied, bookmarked, printed, indexed, cited, opened in another browser, or sent to another person. Local component state usually cannot.
That makes a URL more than a record of which screen happened to be visible. It is a public name for the matter under discussion.
The matter might be an order, a document, a person, a collection, a report, an editing workspace, or a particular view of any of them. The URL does not have to reveal how the server stores that matter. It gives the conversation a stable subject.
This stability solves a human problem before it solves a routing problem. “Look at this” becomes useful only when this can survive the act of sharing.
The Same Name, Different Legitimate Views
Two people can open the same URL without receiving identical pages.
An unauthenticated visitor may receive the public representation. A signed-in contributor may receive editing controls. An owner may receive administrative actions. A person with no relationship to the matter may receive a refusal—or, when revealing its existence would itself leak information, a response indistinguishable from absence.
The URL identifies the subject. The authenticated session supplies authority and context. The backend combines them to decide:
- which representation can be shown;
- which fields can be revealed;
- which actions are currently available;
- which workflow state applies;
- which transition a submitted action may perform.
Availability cannot be decided safely from the browser’s local perspective. The server owns the current authorization and business rules. The client may hide unavailable controls for clarity, but hiding is not enforcement.
Resource, Representation, Activity
A stable name does not imply one frozen rendering.
The resource is the matter being referred to. A representation is what can be said about it from one viewpoint. Activity is what the current participant is doing around it: reading, editing, comparing, approving, paging, filtering, or watching for change.
Keeping those ideas separate helps a web application preserve shareability without pretending that every transient gesture belongs in the URL.
A useful division is:
- put stable subject and meaningful navigation state in the URL;
- keep fleeting interaction state local to the browser;
- keep shared business truth and authorization on the server;
- make intentional drafts durable when losing them would break the user’s process.
The address bar need not encode every open drawer or cursor position. It should encode enough that another participant can arrive at the same matter and establish an appropriate view.
A 3D engine contains a world larger than one frame. The player’s camera selects a position, orientation, and field of view. The engine projects the relevant world state onto the screen.
A web application can be understood the same way.
The path selects a place in the business world. Query parameters may adjust the orientation: page, filter, sort, comparison, or selected subview. The authenticated role constrains where the participant may stand and which objects or actions can appear. The backend then projects a coherent representation for that viewpoint.
resource path + view parameters + authenticated authority
|
v
projected business state
|
v
interactive renderingChanging a route resembles moving the camera to another place. Opening a detail panel resembles bringing one object into focus. Paging or filtering changes what portion of a collection is visible. None of these operations creates the underlying business world. They ask for another projection of it.
The Backend Simulates the Business World
In a multiplayer game, the authoritative world cannot be reconstructed independently by every player from whatever fragments happen to be cached on each machine. The clients render and predict, but the shared simulation has an authority.
Business applications also contain a world that advances: orders change status, inventory becomes unavailable, approvals arrive, deadlines pass, permissions change, and another person edits the same matter.
If the browser must assemble each screen from many generic resources and infer the available actions, it starts rebuilding that world locally. It can combine fresh data with stale permission state, miss a workflow transition, or display an action the server can no longer accept.
The browser should still own what browsers are good at: layout, direct manipulation, transitions, input ergonomics, optimistic feedback, temporary form state, and offline work where the product requires it. The server should answer the business question the current view is asking.
A Projection Should Be Coherent
Suppose the URL names an order list. The useful answer is not merely an array of order records. The visible model may also need selected filters, pagination, display labels, warnings, permissions, available transitions, and links into the next legitimate views.
Returning those facts together lets the server make one statement:
This is what this participant can see and do from this viewpoint now.
That does not require server-rendered HTML. A frontend can receive JSON and render a sophisticated interface. The architectural choice concerns who assembles the business projection, not which side generates the pixels or DOM nodes.
Open tabs can be treated as live views into one shared model.
One person may have a list open while another has a detail view. A third tab may show an approval queue. These are not three private universes. They are three projections whose subjects overlap.
When shared state changes, the server can invalidate or update the affected projections. A tab may subscribe to a narrow event stream, re-request its page-shaped state, merge a conflict into a local draft, or announce that its view is stale. The exact mechanism depends on latency and offline requirements. The important fact is that synchronization follows shared model identity.
The useful metaphor is a reactive view tree rooted in the shared server-side world. It need not be implemented as one literal function tree, and it does not require the frontend to have no state. It means that local views remain answerable to the same shared subjects rather than quietly becoming independent copies.
Where This Architecture Fits
Role-aware projections are especially useful for operational screens, internal tools, approval systems, multi-user editing, admin interfaces, and products where the available action depends on both current workflow state and the participant’s relationship to the matter.
They are a weaker fit for a public integration API whose callers need stable reusable resource contracts, or for a deeply offline client that must advance its own model for long periods and reconcile later. Those systems may still use stable URLs, but they need a different balance of authority and replication.
The camera analogy is a design tool, not a demand that every application use one endpoint per screen. It asks a sharper question: what world is the person looking into, and which side is responsible for producing a truthful view of it?
A Route Contract
For each important URL, define:
- the matter the URL names;
- the meaningful view state encoded in the path or query;
- the authenticated relationships that alter the representation;
- the coherent business state required to render the view;
- the actions available from that state;
- the invalidation or synchronization rule when the shared model changes;
- the local state that should remain private to the browser.
That contract gives the address bar a serious job. It keeps the subject shareable, the authority server-side, the interface expressive, and the many open windows connected to one world.