[leloctai]

As inefficient as encoding everything into the URI is, I really enjoy being able to bookmark and share specific filter configuration. More than one I've seen some sites with UI so bad, that manually editing the url is the easiest way to get it to do what i want.

[itopaloglu83]

Okay, I’m a little confused, the HTTP already supports 8000 octets, and some are having issues because they have too many filters?

Looking at the logs I see that most of the long URI traffic is due to UTM and other tracking related codes, which are mainly a way to work around 3rd party cookie blocks.

I must be missing something, because it sounds like to goal is to have longer URI without the need for encoding URL parameters, but without using POST.

[paulddraper]

Yes.

Suppose you have one filter but it has a few hundred twenty-character values.

[nrhrjrjrjtntbt]

Cough Splunk

Also another case is as a dev you are dealing with guids all day and it can be fast to swap guids around in the browser bar vs. ui steps.

[locknitpicker]

> As inefficient as encoding everything into the URI is, I really enjoy being able to bookmark and share specific filter configuration.

That is perfectly fine. Sites that support path- and query-based filters are already designed specifically to have filters embedded in links, which are GET requests. The QUERY method is something more in line of a GraphQL style of query that isn't held back by the semantics of a POST request. GraphQL didn't invented this API style. If GraphQL-style APIs didn't affected how WebApps implemented links, QUERY methods won't.