We could today implement text-compression. As the above document notes, this should give us 17x space but won't work for things like e.g. selecting all LSOAs. Given the largest (currently loaded) codelist (CPA 08) has around 5000 codes (instead of 35000 for LSOAs) we might expect to get away with this alone. It would defer the problem rather than solving it however.
An alternative would be to use the body for the API request (which could be arbitrary large) and store some state to provide permalinks.
This can happen reasonably easily - try adding the date facet to this example.
There's a lot of ideas on Rick's discussion document for muttnik filters. The current proposal would need data/ workflow changes to enforce immutable ordering of codes.
We could today implement text-compression. As the above document notes, this should give us 17x space but won't work for things like e.g. selecting all LSOAs. Given the largest (currently loaded) codelist (CPA 08) has around 5000 codes (instead of 35000 for LSOAs) we might expect to get away with this alone. It would defer the problem rather than solving it however.
An alternative would be to use the body for the API request (which could be arbitrary large) and store some state to provide permalinks.