In a previous experiment, I created a simple webpage which renders media stored in the URL. This way, it's able to store and render images, audio, and even simple webpages and games. URLs can get quite long, so can store quite a bit of data.
This is because many sites cram the URL full of tracking IDs, and people like to browse without that.
So if you are embedding state in your URL, you probably want to be sure that your application does something sane if the browser strips all of that out.
It only strips known tracking parameters b(like those utm_ query params). It does not remove all parameters; if that's the case, YouTube video links will stop working.
A challenge for this is that the URL is the most visible part of an HTTP request but there are many other submerged parts that are not available as UI yet are significant to the http response composition.
Additionally, aside from very basic protocol, domain, and path, the URL is a very not human friendly UI for composing the state.
Urls are kind of convenient for a lot of things like form parameters, #link into an app or page, etc. That's state. Adding a bit more state via json in a parameter or whatever is about as old as the web is. Mostly, url length restrictions are still a bit of a problem but you need really long urls these days to hit those with most browsers. But aside from that, it's just another way to store stuff between requests.
Why?
I get it if we're talking about a size that flirts with browser limitations. But other than that I see absolutely no problem with this. In fact it makes me think the author is actually underrating the use-case of URL's as state containers.
Depending on which mechanism you use to construct your state URLs they will see them as different pages, so you may end up with a lot of extra traffic and/or odd SEO side effects. For SEO at least there are clear directives you can set that help.
Not saying you shouldn't do this - just things to consider.
https://rssrdr.com/?rss=raw.githubusercontent.com/Roald87/Ha...