JAX-RS/Rest: ¿establece un parámetro varias veces o usa un único parámetro delimitado por comas?

Question

leí que el camino HTTP para pasar una matriz en una solicitud es para establecer un parámetro varias veces:

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

Sin embargo, también he visto el parámetro delimitado por comas (y siento que este es "más limpio "):

2) GET /users?orderBy=last_name,first_name 

Quiero poner en práctica múltiples clasificar (ordenar los usuarios por apellidos y, a continuación, duplicar last_names están clasificadas por nombre apellido). En lo que respecta al código, es fácil (las bibliotecas de Guava de Google al rescate), pero ¿cómo debo exponer esto? ¿La primera manera incluso preserva el orden de los campos (ordena por apellido, luego por primer nombre)?

primavera convertirá mágicamente un parámetro en una matriz String [], si está puesto varias veces en la solicitud:

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

Esto me lleva a creer que la primera manera se considera la mejor práctica, aunque como la segunda manera ...

Answer 1

Creo que es una cuestión de opinión. JAX-RS le permite tener parámetros como:

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

que creo que haría lo mismo que la primavera con respecto a "mágicamente convertir" a parte. No necesariamente creo que esto sea indicativo de una "mejor práctica" o no. Es solo que algunos parámetros pueden tener múltiples valores y los marcos le permiten leer esos valores múltiples (piense en ciertos formularios HTML).

Personalmente, utilizaría un valor único que está delimitado por comas. Es "más limpio" como dijiste y el valor es más fácil de compilar (no dependes del orden de las claves/valores de los parámetros, lo que puede generar problemas para los desarrolladores de los clientes).

Answer 2

El primer método es la forma preferida y estándar.

Sin duda puede usar la segunda forma, pero tendrá que implementar su propia forma de tokenizar el valor del parámetro de solicitud, con todos los problemas que esto conlleva. Por ejemplo, considere qué pasa si uno de sus valores contiene un carácter ','.

Como la primera es bastante estándar, tiene la ventaja de encajar perfectamente con jax-rs y marcos de validación; porque siempre validamos nuestras entradas, ¿verdad? ;)