Do we care about pretty query strings?

[leevigraham]

Possibilities:

Concatenated strings

Example ?ids=1,2,3,4,5

Pros:

• pretty in documentation

Cons:

• Manual construction (implode()) and parsing (explode())
• Not flexible for deeper arrays

Serialised arrays

Example ?ids[]=1&ids[]=2&ids[]=3

Pros:

• Allows for complex filters
• Standard URL behaviour
• Easily constructed / digested
• Symfony2 param convertors expect arrays from query strings

Cons:

• Longer URLS
• Not human readable

Encoded JSON

Example ?q={"ids": [1,2,3,4,5]}

Pros:

• Readable ?

Cons:

• Never seen it done before
• Requires custom parsing
• Seems weird

References:

• Max query string length is 2k: http://www.boutell.com/newfaq/misc/urllength.html http://support.microsoft.com/kb/208427

[leevigraham]

ping @iainsaxon. Thoughts when you get a chance.

[iainsaxon]

The encoded JSON seems a little off as I imagine JSON as an object notation and feels more at home being used for posted data.

The concatenated strings are nice to look at, to write and to document but can often lead to headaches as custom parsing in the model transformers need to be considered. If the transformer hasn't been loaded in at the correct order the form can do unexpected things or simply throw errors.

While it is more unreadable I do think that sticking with serialised query parameters is the more scalable and more programming friendly format of passing query options to the server. It is easy to have the form component utilise the information natively, jQuery can easily serialise the data on the client side and PHP can even store the array as a native serialised object and it 'just works'.