Parámetros de matriz de URL en función de los parámetros de solicitud

Question

Me pregunto si debo usar parámetros matriciales o de consulta en mis URL. Encontré un discussion anterior a ese tema no satisfactorio.

Ejemplos

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

Al principio params matriz vista parecen tener sólo ventajas:

• más legible
• no es necesaria la codificación ni la decodificación de "&" en documentos XML
• URL con "?" no se almacenan en caché en muchos casos; URLs con params matriz se almacenan en caché
• parámetros de la matriz pueden aparecer en cualquier parte del camino y no se limitan a su fin
• parámetros de la matriz pueden tener más de un valor: paramA=val1,val2

Pero también hay desventajas:

• sólo unos marcos como parámetros de la matriz de soporte JAX-RS
• Cuando un navegador envía un formulario a través de GET, los parametros 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 param 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

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 al realizar una consulta compleja estilo REST a múltiples niveles de recursos y sub-recursos:

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

Todo se reduce a los espacios de nombre. 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 son generalmente mejor admitidos 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.

Answer 2

--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

Por lo tanto, la respuesta breve es que si necesita RS para fines comerciales, es mejor que use el parámetro de solicitud.

Answer 3

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

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

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

   Puede acceder a ellos utilizando 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 Javadoc

   Nota que el valor @MatrixParam anotación se refiere a un nombre de un parámetro de matriz que reside en el segmento última ruta emparejado de la estructura Java Path-anotado que inyecta el valor del parámetro de la matriz.

   ... lo que nos lleva al punto 2

2. parámetros de la 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 @PathParamPathSegment.

   @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] 
   

   Dado que los parámetros de la matriz se proporcionan como un MultivaluedMap se puede acceder a cada uno por

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

   o si sólo necesita el primero

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

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

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

   Utilice un List<PathSegment> a llegar a todos ellos Respuesta

   @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(); 
   } 
   

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