Live data from Hacker News

URLs are state containers

alfy.blog

1–10 of 218 posts

Re: URLs are state containers

#3
post #2

Not quite. As the L in URL says, it is the locator or address of the state. The S in REST implies the same, indicating states as the content, not path to it.

But from the viewpoint of a web app where you navigate between different (versions of) pages, the state of that app can be the address of the currently displayed page.

Re: URLs are state containers

#4
When the system evolves, you need to change things. State structure also evolves and you will refactor and rework it. You'll rename things, move fields around.

URL is considered a permanent string. You can break it, but that's a bad thing.

So keeping state in the URL will constrain you from evolving your system. That's bad thing.

I think, that it's more appropriate to treat URL like a protocol. You can encode some state parameters to it and you can decode URL into a state on page load. You probably could even version it, if necessary.

For very simple pages, storing entire state in the URL might work.

Re: URLs are state containers

#5

When the system evolves, you need to change things. State structure also evolves and you will refactor and rework it. You'll rename things, move fields around. URL is considered a permanent string. You can break it, but that's a bad thing. So keeping state in the URL will constrain you from evolving your system. That's bad thing. I think, that it's more appropriate to treat URL like a protocol. You can encode some st…

[deleted]

Re: URLs are state containers

#6
To fully describe client side state you also need to look at DOM and cookies. The server can effectively see this stuff too (e.g., during form post).

I design my SSR apps so that as much state as possible lives in the server. I find the session cookie to be far more critical than the URL. I could build most of my apps to be URL agnostic if I really wanted to. The current state of the client (as the server sees it) can determine its logical location in the space of resources. The URL can be more of an optional thing for when we do need to pin down a specific resource for future reference.

Another advantage of not urlizing everything is that you can implement very complex features without a torturous taxonomy. "/workflow/18" is about as detailed as I'd like to get in the URL scheme of a complex back office banking product.

Re: URLs are state containers

#8
I agree, and this reminds me: I really wish there was better URL (and DNS) literacy amongst the mainstream 'digitally literate'. It would help reduce risk of phishing attacks, allow people to observe and control state meaningful to their experience (e.g. knowing what the '?t=_' does in youtube), trimming of personal info like tracking params (e.g. utm_) before sharing, understanding https/padlock doesn't mean trusted. Etc. Generally, even the most internet-savvy age group, are vastly ill-equipped.

Re: URLs are state containers

#9
The amount of state that early video games stored in like 256 bytes of ram was actually quite impressive. I bet with some creativity one could do similarly for a web app. Just don’t use gzipped b64-encoded json as your in-url state store!
Post reply on HN