JAX-RS / Rest: установить параметр несколько раз или использовать один параметр, разделенный запятыми?

Question

Я прочитал, что HTTP-способ передачи массива в запросе - установить параметр несколько раз:

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

Однако я также видел параметр, разделенный запятыми (и я чувствую, что он «чище»):

2) GET /users?orderBy=last_name,first_name

Я хочу реализовать мультисортировку (упорядочение пользователей по фамилии, затем дубликаты по фамилиям, по фамилии). С точки зрения кода, это легко (библиотеки Guava от Google на помощь), но как мне это разоблачить? Сохраняет ли первый способ порядок полей (сортировка по last_name, затем по first_name)?

Spring волшебным образом преобразует параметр в массив String [], если он задан в запросе несколько раз:

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

Это заставляет меня верить, что первый способ считается наилучшей практикой, хотя мне нравится второй способ ...

Answer 1

Первый способ является предпочтительным, стандартным способом.

Конечно, вы можете использовать второй способ, но вам придется реализовать свой собственный способ токенизации значения параметра запроса со всеми возникающими проблемами.Например, рассмотрим, что произойдет, если одно из ваших значений будет содержать символ «,».

Поскольку первое является вполне стандартным, оно имеет преимущество в том, что оно хорошо согласуется с jax-rs и средами валидации;потому что мы всегда проверяем наши данные, верно?;)

Answer 2

Я думаю, что это вопрос мнения. JAX-RS позволяет вам иметь такие параметры, как:

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

, что, я думаю, сделало бы то же самое, что и Spring, в отношении "волшебного преобразования" части. Я не обязательно думаю, что это свидетельствует о «лучшей практике» или нет. Просто у некоторых параметров может быть несколько значений, а фреймворки позволяют вам читать эти несколько значений (например, определенные формы HTML).

Лично я бы использовал одно значение, разделенное запятыми. Он «чище», как вы сказали, и его значение легче построить (вы не полагаетесь на порядок ключей / значений параметров, который может привести к некоторым проблемам для разработчиков клиентов).