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

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

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

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

2) GET /users?orderBy=last_name,first_name

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

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

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

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

Ответ 1

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

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

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

Ответ 2

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

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

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

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