What character may (and should) I use as internal separators for my field values in URL query string?

Question

I am developing a web application that uses both URL routes and query string parameters. Some of my parameters contain complex lists and require some internal separators. For example I need a filter to support several entities, like usernames and dates.

Basically I need to encode the following JSON-object:

{
"users" : ["alex","mike","john"],
"datefrom" : "2013-12-01"
}

as one querystring parameter (filter).

I have several ideas:

_http://hostedapplication/?filter=users@alex,mike,john;datefrom@2013-12-01

_http://hostedapplication/?filter=users|alex,mike,john!datefrom|2013-12-01

So, what are the typical approaches here? What characters I might use for my separators?

Answer 1

For a REST interface, it's pretty common to use GET parameters as filters for a GET request. So the top-level filter params you could use as GET parameters, and if you go a level deeper you could indeed use separators for Arrays.

In that case, there is not really a standard way to do it, REST doesn't have rules for that, so you can decide for yourself. Personally, i like comma's:

?users=alex,mike,john&datefrom=2013-12-01

Just note that if any of the users have usernames that contain URL control characters, you should url encode them.

Answer 2

Have a look at this filter implementation ... https://developers.google.com/ad-exchange/seller-rest/filters ... The separator that can be used should be an unique one that is not used in the resource name (users).

Answer 3

The standard approach (from the HTML form implementation) is to repeat the key each time it has a new value:

 ?user=alex&user=mike&user=john&datefrom=2013-12-01

Most libraries that will parse form data will give you an array when you ask for user automatically.

(If you are using PHP then you will need to use user[] instead of user).

The drawback of this approach is that it is not very compact so you risk running into URL length limits sooner if you have a lot of data.