The address bar can leave the application. People copy, bookmark, print, index, cite, reopen, and send its URL. Local component state rarely travels so well.
A URL therefore names the matter under discussion and outlives the screen that happened to appear.
That matter may take the form of an order, document, person, collection, report, editing workspace, or a meaningful view of one. The URL can identify it without exposing the server’s storage model.
This stability solves a human problem before a routing problem. A reference becomes useful when its subject survives the act of sharing.
One Name Supports Several Authorized Views
Two people can open the same URL and receive views appropriate to their relationships with the subject.
A visitor sees the public representation. A signed-in contributor sees editing controls. An owner sees administrative actions. A person without access receives a refusal—or an ordinary not-found response when the resource’s existence itself requires protection.
The URL identifies the subject. The authenticated session supplies authority and context. The backend combines them to decide:
- which representation to show;
- which fields to reveal;
- which actions are currently available;
- which workflow state applies;
- which transition a submitted action can perform.
The server owns current authorization and business rules, so it decides availability. The client can hide unavailable controls for clarity; the server still enforces every action.
Separate Subject, View, And Activity
A stable name can support many living views.
The resource supplies the subject. A representation describes that subject from one authorized viewpoint. Activity describes what the participant does around it: reading, editing, comparing, approving, paging, filtering, or watching for change.
This separation preserves shareability while keeping transient gestures out of the route.
A useful division is:
- name the stable subject and meaningful navigation state in the URL;
- keep fleeting interaction state inside the browser;
- keep shared business truth and authorization on the server;
- save intentional drafts whenever loss would interrupt the user’s work.
The address bar should carry enough state for another participant to reach the same matter and establish an appropriate view. Open drawers and cursor positions can remain local.
A 3D engine holds 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 use the same architecture.
The path selects a place in the business world. Query parameters adjust orientation through page, filter, sort, comparison, or subview. The authenticated role constrains where the participant may stand and which objects or actions may appear. The backend projects a coherent representation from that viewpoint.
resource path + view parameters + authenticated authority
|
v
projected business state
|
v
interactive renderingA route change moves the camera. A detail panel brings one object into focus. Paging and filtering alter the visible portion of a collection. Each operation requests another projection of the same underlying world.
The Backend Simulates the Business World
In a multiplayer game, one authoritative simulation advances the shared world. Clients render, predict, and cache fragments, but they remain answerable to that common state.
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.
When the browser assembles each screen from generic resources and infers the available actions, it begins rebuilding the business world locally. Fresh data can then meet stale permissions, a workflow transition can go unseen, or the interface can offer an action that the server rejects.
The browser should own layout, direct manipulation, transitions, input ergonomics, optimistic feedback, temporary form state, and product-specific offline work. The server should answer the business question that the current view asks.
Return The Complete View In One Projection
Suppose the URL names an order list. A useful answer carries the order records alongside selected filters, pagination, display labels, warnings, permissions, available transitions, and links into the next authorized views.
Returning those facts together lets the server make one coherent statement:
This is what this participant can see and do from this viewpoint now.
The frontend can receive JSON and render a sophisticated interface. The architectural choice determines who assembles the business projection; it leaves pixel and DOM generation free to follow the product’s needs.
Each open tab can remain a live view into one shared model.
One participant may hold a list open while another studies a detail view and a third watches an approval queue. These projections overlap through common subjects instead of becoming private universes.
When shared state changes, the server can invalidate or update every affected projection. A tab may subscribe to a narrow event stream, request its page-shaped state again, merge a conflict into a local draft, or mark its view stale. Latency and offline needs choose the mechanism; shared model identity determines what synchronizes.
A reactive view tree rooted in the server-side world captures the design. The frontend still keeps the local state that makes interaction fluid, while every durable view remains answerable to the same shared subjects.
Match Authority And Replication To The Product
Role-aware projections excel in operational screens, internal tools, approval systems, multi-user editing, admin interfaces, and products where workflow state and participant relationships determine the next action.
Public integration APIs emphasize stable reusable resource contracts. Deeply offline clients advance local models for long periods and reconcile later. Both can keep stable URLs while choosing a different balance between server authority and client replication.
The camera analogy asks the decisive architectural question: what world is the person looking into, and which component produces the coherent view?
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.
This contract gives the address bar a serious job: keep the subject shareable, authority server-side, interaction expressive, and every open window connected to one world.