How to compress URL parameters

后端 未结 12 1508
孤城傲影
孤城傲影 2020-12-04 11:16

Say I have a single-page application that uses a third party API for content. The app’s logic is in-browser only, and there is no backend I can write to.

To allow de

12条回答
  •  难免孤独
    2020-12-04 11:47

    It looks like the Github APIs have numeric IDs for many things (looks like repos and users have them, but labels don't) under the covers. It might be possible to use those numbers instead of names wherever advantageous. You then have to figure out how to best encode those in something that'll survive in a query string, e.g. something like base64(url).

    For example, your hoodie.js repository has ID 4780572.

    Packing that into a big-endian unsigned int (as many bytes as we need) gets us \x00H\xf2\x1c.

    We'll just toss the leading zero, we can always restore that later, now we have H\xf2\x1c.

    Encode as URL-safe base64, and you have SPIc (toss any padding you might get).

    Going from hoodiehq/hoodie.js to SPIc seems like a good-sized win!

    More generally, if you're willing to invest the time, you can try to exploit a bunch of redudancies in your query strings. Other ideas are along the lines of packing the two boolean params into a single character, possibly along with other state (like what fields are included). If you use base64-encoding (which seems the best option here due to the URL-safe version -- I looked at base85, but it has a bunch of characters that won't survive in a URL), that gets you 6 bits of entropy per character... there's a lot you can do with that.

    To add to Thomas Fuchs' note, yes, if there's some kind of inherent, immutable ordering in some of things you're encoding, than that would obviously also help. However, that seems hard for both the labels and the milestones.

提交回复
热议问题