How are you compressing your URIs or query string for HTTP GET methods?

Enrique Molinari

We are looking for some feedback about how we can compress/decompress query string parameters in HTTP GET methods. For some applications, we have very large URIs, and we don't want to move to the POST Method. Are there any doing this in TR, to share how this was done ?

Ryan Morlok

I've done a few things to try to compress URIs to keep them under the ~2000 character limit.

The first (and most obvious) is to use short names for query string parameters. Instead of full words for parameter names, go down into single character names. Obviously this hurts the readability of your code and URIs.

The second is to use integer values or shorted values for things that are essentially enums. E.g. if you had a parameter that accepted the possible countries as values, establish a mapping as part of your contract that 1=Canada, 2=Mexico, etc. Again, readability suffers here.

The final approach that can be done is aggregating data into opaque fields that can be compressed in some way. An example of this would be to combine multiple parameters into a single value, compress it, and pass it as single Base64 encoded parameter. Again, readability really suffers, and you have have to be careful that the final parameter will actually be smaller than the data you started with.

Most of these techniques I haven't done on Thomson Reuters applications, but rather my own projects.

Enrique Molinari

Thanks for your answer Ryan.

paul.buchanan.1

Another approach may be to adopt a POST/GET model if you need to pass a lot of information. You could POST a request to "create" a resource which would return a resource handle of some kind. This is then followed up with a GET for that created resource. This adds some complexity however. You will either need server affinity (ie POST and GET to the same server) or you will need a shared resource to store the results that all your severs can read from. Some examples are a NAS filesystem, a database, or a shared cache like coherence. Another thing to keep in mind is that we need to be pragmatic when using REST. Even though the semantics of a POST may not match what your endpoint is accomplishing, it may make sense to use a POST anyway to avoid additional complexity and overhead. This struggle with the GET URL limit comes up all the time and has no easy answers.

James Greene

The only other thing I would add to Ryan's answer is that if you have several enumerated value (or a finite set of expected values) fields, then you could come up with shorthands for all of the possible combinations, e.g. `?cty=mx&lang=es` might become `?loc=mx-es`, or `opt1=value1&opt2=value2&opt3=value3` might become `?opts=knownCombo1`. Again, readability suffers.