is this not a basic rest principle? URLs and req/res bodies are the only way to transfer anything so they must be the way to transfer state
URLs are state containers
201–210 of 218 posts
Re: URLs are state containers
#202HATEOAS never gets the love it deserves until you call it something else.. Probably because it sounds like the most poorly named breakfast cereal ever.
> HATEOAS ... sounds like the most poorly named breakfast cereal ever.
I think of flight stick controllers.
Re: URLs are state containers
#203Sounds like ASP.Net Web Forms! Except it would fall apart anyway when you would reload!
Re: URLs are state containers
#204It’s kind of nuts this even has to be explained. I had a coworker I’ve been trying to teach good application design and React state is the first “crap bucket” he always reaches for. I had to explain to him, “when we put values in the Url we don’t need to use state, because everything is already stored right?” “Uhhh sure fine go ahead and change it.”
But what bugs me about it is that this isn’t even that novel or intelligent of a realization. If you’ve used a web browser you’ve seen the url change. Connecting that with putting values in the url shouldn’t be such a huge leap. This was for a simple search page.
How do I stop this sort of brain dead unrealized thinking?
Re: URLs are state containers
#205Earlier quoted context omitted.
Links with lots of data in them are really annoying to share. I see the value in storing some state there, but I don’t think there is room for much of it.
What makes them annoying to share? I bet it's more an issue with the UX of whatever app or website you're sharing the link in. Take that stackoverflow link in the comment you're replying to, for example: you can see the domain and most of the path, but HN elides link text after a certain length because it's superfluous.
SO links require just the question ID; short enough to memorize.
Re: URLs are state containers
#206The new web standard initiative BRAID is trying to make web to be more human and machine friendly with a synchronous web of state [1],[2],[3]. "Braid’s goal is to extend HTTP from a state transfer protocol to a state sync protocol, in order to do away with custom sync protocols and make state across the web more interoperable. Braid puts the power of operational transforms and CRDTs on the web, improving network perf…
They should create a Wikipedia page for it.
Re: URLs are state containers
#207When I get my way reviewing a codebase, I make sure that as much state as possible is saved in a URL, sometimes (though rarely) down to the scroll position. I genuinely don't understand why people don't get more upset over hitting refresh on a webpage and ending up in a significantly different place. It's mind-boggling and actually insulting as a user. Or grabbing a URL and sending to another person, only to find out…
I worked at a company that worked hard to make urls do heavy lifting for so many tasks, and it was freaking great.
Re: URLs are state containers
#208When I get my way reviewing a codebase, I make sure that as much state as possible is saved in a URL, sometimes (though rarely) down to the scroll position. I genuinely don't understand why people don't get more upset over hitting refresh on a webpage and ending up in a significantly different place. It's mind-boggling and actually insulting as a user. Or grabbing a URL and sending to another person, only to find out…
"hitting refresh"
You made my day. I totally agree with you: state, state management, UX/UI.
I am extremely proud that I lately implemented exactly this: What if... you pass a link or hit reload - or back button in browser.
I have a web app that features a table with a modal preview when hitting a row - boy am I proud to have invested 1 hour in this feature.
I like your reasoning: it ain't a technical "because I can dump anything in a url", nope, it is a means to an end, the user experience.
Convenience, what ever. I have now a pattern to put in more convenience like this, which should be pretty normal.
The only think that remains and bothers me is the verbose URL - the utter mess and clutter in the browser's input field. I feel pain here and there is a conflict inside me between URL aesthetics and flatter the user by providing convenience.
I am working on a solution, because this messy URL string hurts my eyes and takes away a little bit the magic and beauty of the state transfer. This abstract mess should be taken care of, also in regard to obfuscation. It ain't cleanly to have full-text strings in the URL, with content which doesn't belong there.
But I am on it. I cannot leave the URL string out of the convenience debate, especially not on mobile. Also it can happen that strings get stripped or copy & paste accidentally cut of parts. The shorter the better and as we see, convenience is a brutally hard job to handle. Delicate at so many levels, here error handling due to wrongly formatted strings, a field few people ever entered.
My killer feature is the initial page load - it appears way more faster, since there are no skeletons waiting for their fetch request to finish. I am extremely impressed by this little feature and its impact on so many levels.
Cheers!
Re: URLs are state containers
#209When I get my way reviewing a codebase, I make sure that as much state as possible is saved in a URL, sometimes (though rarely) down to the scroll position. I genuinely don't understand why people don't get more upset over hitting refresh on a webpage and ending up in a significantly different place. It's mind-boggling and actually insulting as a user. Or grabbing a URL and sending to another person, only to find out…
First SPA I built (without frameworks) I actually wrote my own router that stored most client-side state in the URL as a hash. I remember back then having some problems with IE6 4kb limit on URL length.
It actually worked really well, but obviously I had very little state. The only things I didn't store in the hash were form state and raw visualization data (like chart data).
Re: URLs are state containers
#210HATEOAS never gets the love it deserves until you call it something else.. Probably because it sounds like the most poorly named breakfast cereal ever.
This has nothing to do with HATEOAS. Well, apart from both using URLs. But HATEOAS really isn’t about storing state in URLs.
> But HATEOAS really isn’t about storing state in URLs.
I think saying they are unrelated isn't correct either. In order for hypermedia to be the engine of application state, the continuations of your application must be reified as URLs, ie. they must be stateful. This state could be stored server-side or in the URL, it doesn't matter, as URLs are only meaningful to the server that generated and interprets them.