Representing ~200 boolean flags in a URL query

Question

A public web service accepts configuration options via URL. Each request will use about 20 of the available 200 options, and each one is a true or false value. The service is stateless and responses will be cached.

Typical example so far:

http://api.milk.shake/?likesVanilla&likesChocolate=true&likesStrawberry=true

Assume each value is false unless specified, so shortened to:

http://api.milk.shake/?likesVanilla&likesChocolate&likesStrawberry

The generated URLs are still long and unweildy for 20 options. How can I make them shorter, tidy and keep them valid and usable in the wild?

In examples below assume URL rewriting converts URIs into query parameters

Approach 1 - Assign a character to each option

For example A = likesVanilla, B = likesChocolate, C = likesStrawberry

Typical call would be http://api.milk.shake/ABC

Fails because URLs can use A-Z, a-z, 0-9 and $-_.+!*'(), which only covers 73 of the available 200 options.

Approach 2 - Binary representation

For example 1 = likesVanilla, 2 = likesChocolate, 4 = likesStrawberry

Typical call would be http://api.milk.shake/7 (dec or hex maybe)

Where 7 = 1 + 2 + 4 = vanilla + chocolate + strawberry

Fails because exponentials are exponential - the 63rd option has an array index of 4611686018427387904 and the 64th option breaks PHP unless I'm testing it wrong..

Efficient because parameter order is unified and all similar requests are cached.

Approach 3 - Grouping with 1 or 2

I could define groups of options within the URL. This limits the number of available options in each group and allows approach 1 or 2.

For example:

Group 1 options A = likesVanilla, B = likesChocolate, C = likesStrawberry

Group 2 options A = likesCream, B = likesSprinkles

Typical call would be http://api.milk.shake/ABC/AB (first group / second group etc)

This is my preferred approach so far. May be answering my own question!

Approach 4 - Escaped characters

If characters are escaped correctly then about 220 characters become available.

Typical call would be http://api.milk.shake/%41%42%43

Maximum 220 options is not future-proof but could be used with Approach 3. Looks untidy.

Your POSTing configuration options, so why not use POST instead of GET? — Vincent Beltman, Mar 09 '16 at 15:19
What about numeric representation of each option, i.e. `http://api.milk.shake/1/6/45/123/7/34/199`? — mitkosoft, Mar 09 '16 at 15:21
@mitkosoft Good idea.. dec or hex as you show would make a good potential answer ;) — NoChecksum, Mar 09 '16 at 15:31
@NoChecksum, yes, hex is even better because you can represent up to 255 options with only 2 symbols (FF). — mitkosoft, Mar 09 '16 at 15:48
@VincentBeltman I think GET requests are simpler, slightly easier to use and (I think) easier to cache. POST is possible if necessary — NoChecksum, Mar 09 '16 at 15:49

score 1 · Answer 1 · answered Mar 09 '16 at 16:28

1

Option 2 could work if you break the options into smaller sets, say 4 sets of 50 bits each.

Just realised you've said as much already as Option 3, hadn't got that far. However, you might be able to use BCMath to do it as one large integer.

answered Mar 09 '16 at 16:28

AntonChanning

509
2
13
37

score -1 · Answer 2 · answered Mar 09 '16 at 15:42

-1

Is there a reason you need it to be a GET? With that many potential parameters it seems like a POST would be a better option and gets around the URL length issue.

answered Mar 09 '16 at 15:42

MajicBob

487
2
8

Representing ~200 boolean flags in a URL query

2 Answers2