http - query - Parámetros de matriz de URL vs. parámetros de solicitud

jax-rs tutorial español

Question

Me pregunto si usar parámetros matriciales o de consulta en mis URL. Encontré una discussion anterior discussion ese tema que no me satisfizo.

Ejemplos

• URL con params de consulta: http://some.where/thing?paramA=1&paramB=6542
• URL con parámetros de matriz: http://some.where/thing;paramA=1;paramB=6542

A primera vista, los parametros de matriz parecen tener solo ventajas:

• más legible
• no se requiere codificación y descodificación de "&" en documentos XML
• URL con "?" no se almacenan en caché en muchos casos; Las URL con parámetros de matriz se almacenan en caché
• los parámetros de la matriz pueden aparecer en todas partes en la ruta y no están limitados a su fin
• los parámetros de matriz pueden tener más de un valor: paramA=val1,val2

Pero también hay desventajas:

• solo unos pocos frameworks como JAX-RS soportan parámetros de matriz
• Cuando un navegador envía un formulario a través de GET, los parámetros se convierten en parámetros de consulta. Entonces termina en dos tipos de parámetros para la misma tarea. Para no confundir a los usuarios de los servicios REST y limitar el esfuerzo para los desarrolladores de los servicios, sería más fácil usar siempre params de consulta, en esta área.

Dado que el desarrollador del servicio puede elegir un marco con soporte de matriz de matriz, la única desventaja restante sería que los navegadores crean por parámetros de consulta predeterminados.

¿Hay alguna otra desventaja? ¿Qué harías?

Answer 1

- Demasiado importante para ser relegado a la sección de comentarios .--

No estoy seguro de cuál es el problema con las URL matriciales. De acuerdo con el artículo de diseño de w3c que TBL escribió, era solo una idea de diseño y declara explícitamente que no es una característica de la web. Las cosas como las URL relativas no se implementan cuando se usa. Si quieres usarlo, está bien; simplemente no hay una forma estándar de usarlo porque no es un estándar. - Steve Pomeroy

Entonces, la respuesta corta es que si necesita RS para fines comerciales, es mejor que use el parámetro de solicitud.

Answer 2

Además de la respuesta de Tim Sylvester, me gustaría ofrecer un ejemplo de cómo se pueden manejar los parámetros de la matriz con JAX-RS .

1. Parámetros de Matix en el último elemento de recurso

   http://localhost:8080/res/categories/objects;name=green

   Puede acceder a ellos usando la anotación @MatrixParam

   @GET
   @Path("categories/objects")
   public String objects(@MatrixParam("name") String objectName) {
     return objectName;
   }

   Respuesta

   green

   Pero al igual que los estados de javadoc

   Tenga en cuenta que el valor de la anotación de @MatrixParam refiere a un nombre de un parámetro de matriz que reside en el último segmento de ruta coincidente de la estructura de Java anotada por ruta que inyecta el valor del parámetro de matriz.

   ... lo que nos lleva al punto 2

2. Parámetros de matriz en el medio de una URL

   http://localhost:8080/res/categories;name=foo/objects;name=green

   Puede acceder a los parámetros de la matriz en cualquier lugar utilizando variables de ruta y @PathParam PathSegment .

   @GET
   @Path("{categoryVar:categories}/objects")
   public String objectsByCatecory(@PathParam("categoryVar") PathSegment categorySegment, 
                                   @MatrixParam("name") String objectName) {
     MultivaluedMap<String, String> matrixParameters = categorySegment.getMatrixParameters();
     String categorySegmentPath = categorySegment.getPath();
     String string = String.format("object %s, path:%s, matrixParams:%s%n", objectName,
             categorySegmentPath, matrixParameters);
     return string;
   }

   Respuesta

   object green, path:categories, matrixParams:[name=foo]

   Como los parámetros de matriz se proporcionan como MultivaluedMap , puede acceder a cada uno de ellos mediante

   List<String> names = matrixParameters.get("name");

   o si solo necesitas el primero

   String name = matrixParameters.getFirst("name");

3. Obtenga todos los parámetros de matriz como un parámetro de método

   http://localhost:8080/res/categories;name=foo/objects;name=green//attributes;name=size

   Use una List<PathSegment> para obtenerlos a todos

   @GET
   @Path("all/{var:.+}")
   public String allSegments(@PathParam("var") List<PathSegment> pathSegments) {
     StringBuilder sb =  new StringBuilder();
   
     for (PathSegment pathSegment : pathSegments) {
       sb.append("path: ");
       sb.append(pathSegment.getPath());
       sb.append(", matrix parameters ");
       sb.append(pathSegment.getMatrixParameters());
       sb.append("<br/>");
     }
   
     return sb.toString();
   }

   Respuesta

   path: categories, matrix parameters [name=foo]
   path: objects, matrix parameters [name=green]
   path: attributes, matrix parameters [name=size]

Answer 3

La diferencia importante es que los parámetros de matriz se aplican a un elemento de ruta en particular mientras que los parámetros de consulta se aplican a la solicitud como un todo. Esto entra en juego cuando se hace una consulta compleja de estilo REST a múltiples niveles de recursos y sub-recursos:

http://example.com/res/categories;name=foo/objects;name=green/?page=1

Realmente se reduce al espacio de nombres. Si solo se utilizaran parámetros de consulta, terminaría con parámetros como "nombre_categoría" y "nombre_objeto" y perdería la claridad agregada por la localidad de los parámetros dentro de la solicitud. Además, al usar un marco como JAX-RS, todos los parámetros de consulta aparecerían dentro de cada manejador de recursos, lo que generaría conflictos y confusión.

Si su consulta tiene solo un "nivel", entonces la diferencia no es realmente importante y los dos tipos de parámetros son efectivamente intercambiables, sin embargo, los parámetros de consulta generalmente son mejor compatibles y más ampliamente reconocidos. En general, recomendaría que se apegue a los parámetros de consulta para cosas como formularios HTML y API HTTP simples de un solo nivel.