Question: I read that the HTTP way to pass an array in a request is to set a parameter multiple times:

```
1) GET /users?orderBy=last_name&orderBy=first_name

```

However, I've also seen the comma-delimited parameter (and I feel this is "cleaner"):

```
2) GET /users?orderBy=last_name,first_name

```

I want to implement multi-sorting (ordering users by last\_name, then duplicate last\_names are ordered by first\_name). Code-wise, this is easy (Google's Guava libraries to the rescue), but how should I expose this? Does the first way even preserve the order of the fields (sort by last\_name, then by first\_name)?

Spring will magically convert a parameter into a String[] array, if it is set multiple times in the request:

```
... @RequestParam("orderBy") String[] orderBy ... becomes ["last_name","first_name"]

```

This leads me to believe the first way is considered best-practice, although I like the second way...

Answer: 
The first method is the preferred, standard way. 

You can certainly use the second way, but you will have to implement your own way of tokenizing the request parameter value, with all the issues that involves. For example, consider what happens if one of your values contains a ',' character.

Because the first is quite standard, it has the benefit of fitting in nicely with jax-rs, and validation frameworks; because we always validate our inputs, right? ;)
I think it's a matter of opinion. JAX-RS allows you to have parameters like:

```
@QueryParam("orderBy") List<String> orderBy

```

which I think would do the same thing as Spring regarding "magically convert" part. I don't necessarily think this is indicative of a "best practice" or not. It's just that some parameters can have multiple values and the frameworks allow you to read those multiple values (think certain HTML forms).

Personally, I would use a single value that's comma delimited. It's "cleaner" like you said and the value is easier to build (you're not relying on the order of parameter key/values which can lead to some trouble for client developers).