Birbla

Join the discussion

Write your take first — we'll ask for email only when you're ready to publish.

Sign in
  • Hacker News
  • HATEOAS never gets the love it deserves until you call it something else..

    Probably because it sounds like the most poorly named breakfast cereal ever.

    by caseysoftware
  • Unfortunately, too many websites use tracking parameters in URLs, so when a URL is too long I tend to assume it's tracking and just remove all the extra parameters from it when saving or sending it to anyone.

    Though I guess this won't happen if it's obvious at first glance what the parameters do and that they're all just plaintext, not b64 or whatever.

    by flexagoon
  • 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.

    by vbezhenar
  • > Browsers and servers impose practical limits on URL length (usually between 2,000 and 8,000 characters) but the reality is more nuanced. As this detailed Stack Overflow answer explains, limits come from a mix of browser behavior, server configurations, CDNs, and even search engine constraints. If you’re bumping against them, it’s a sign you need to rethink your approach.

    So what is the reality? The linked StackOverflow answer claims that, as of 2023, it is "under 2000 characters". How much state can you fit into under 2000 characters without resorting to tricks for reducing the number of characters for different parameters? And what would a rethought approach look like?

    by azangru
  • Recommendation:

    https://github.com/Nanonid/rison

    Super old but still a very functional library for saving state as JSON in the URL, but without all the usual JSON clutter. I first saw it used in Elastic's Kibana. I used it on a fancy internal React dashboard project around 2016, and it worked like a charm.

    Sample: http://example.com/service?query=q:'*',start:10,count:10

    by dzhar11
  • If the URL is your state container, it also becomes a leakage mechanism of internals that, at the very least, turns into a versioning requirement (so an old bookmark won’t break things). That also means that there’s some degree of implicit assumption with browsers and multi-browser passing. At some point, things might not hold up (Authentication workflows, for example).

    That said, I agree with the point and expose as much as possible in the URL, in the same way that I expose as much as possible as command line arguments in command line utilities.

    But there are costs and trade offs with that sort of accommodation. I understand that folks can make different design decisions intentionally, rather than from ignorance/inexperience.

    by chaboud
  • 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.
    by padolsey
  • When 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 it doesn't make sense.

    Developing like this on small teams also tends, in my experience, to lead to better UX, because it makes you much more aware of how much state you're cramming into a view. I'll admit it makes development slower, but I'll take the hit most days.

    I've seen some people in this thread comment on how having state in a URL is risky because it then becomes a sort of public API that limits you. While I agree this might be a problem in some scenarios, I think there are many others where that is not the case, as copied URLs tend to be short-lived (bookmarks and "browser history" are an exception), mostly used for refreshing a page (which will later be closed) or for sharing . In the remaining cases, you can always plug in some code to migrate from the old URL to the new URL when loading, which will actually solve the issue if you got there via browser history (won't fix for bookmarks though).

    by jorl17

Explore Birbla archives