0

I'm building a web app where in certain cases users may want to deep link to a state consisting of a list of items to have some action carried out upon.

We are considering whether to serialize the state on the URL or implement a solution that will persist the state on the backend and provide an ID to look it up.

So the url-scheme would either be something like:

/batch/item-1&item-2&item-3

Or:

/batch/4jk5kjdl3k

Where 4jk5kjdl3k represents an ID which allows the backend to lookup the list of item IDs.

We do not care about SEO in this instance as it is an editing interface that will not generally be crawlable or meaningful to search engines. From my research IE has a limit of 2083 characters and SEO sitemaps 2048 characters. We should be able to keep URL lengths below either limit. In the typical use case scenario we would sit somewhere around 200-500 characters, but there could be extreme cases getting close to 2000.

If we serialize the state on the URL directly, we can save a fair amount of work on the backend, but I'm worried that I'm overlooking some disadvantages to these potentially very long URLs.

I found this question on the topic, but it appears to be more concerned with the matter of exceeding 2083 characters:

What is the maximum length of a URL in different browsers?

So far the only disadvantages I see are:

  • Perhaps the IDs we store could change design and become longer in the future and bump us over the limit (quite unlikely)
  • These very long URLs can seem a bit unwieldy for users to deal with when copy/pasting and they could potentially end up cutting them off by accident

For context, the app is built in React, but I don't think that should be a determining factor.

zkwsk
  • 1,960
  • 4
  • 26
  • 34
  • 1
    its common to pass things in the URL, the url-schemes you mention are typical, most sites would use /batch?items[]=item-1&items[]=item-2 though, your first url-scheme is not standard but its ok if you want to faff with parsing, the second one is common for link shortener sites, or youtube for example, though there is nothing wrong with dumping state into a huge var, much like https://www.typescriptlang.org/play does on sharing, it all depends on the app and personal preference if you want long or short URLs – Lawrence Cherone Oct 04 '22 at 17:57
  • Fun that you mention typescriptlang.org. I did a presentation recently and was annoyed that when I tried to copy/paste links to examples into my presentation it would basically break the layout because the presentation editor would try very hard to display the full URL on screen. But that is probably quite the edge-case. – zkwsk Oct 04 '22 at 18:03
  • yeah it has its drawbacks, compression can only go so far, which then your need base64/91 URL safe it anyway, messy. its always better to store in a db if you can, then just pass an id, if you want it none sequentual use something like hashids – Lawrence Cherone Oct 04 '22 at 18:13

0 Answers0