pathparam - queryparam java

Cuándo usar @QueryParam vs @PathParam

Question

No estoy haciendo la pregunta que ya se hace aquí: ¿Cuál es la diferencia entre @PathParam y @QueryParam

Esta es una pregunta de "mejores prácticas" o convención.

¿Cuándo @PathParam vs @QueryParam ?

En lo que puedo pensar es que la decisión podría estar utilizando los dos para diferenciar el patrón de información. Permítanme ilustrar a continuación mi LTPO - observación menos que perfecta.

El uso de PathParam podría reservarse para la categoría de información, que se incluiría en una rama de un árbol de información. PathParam podría usarse para profundizar en la jerarquía de clases de entidad.

Considerando que, QueryParam podría reservarse para especificar atributos para localizar la instancia de una clase.

Por ejemplo,

• /Vehicle/Car?registration=123
• /House/Colonial?region=newengland

/category?instance

@GET
@Path("/employee/{dept}")
Patient getEmployee(@PathParam("dept")Long dept, @QueryParam("id")Long id) ;

vs /category/instance

@GET
@Path("/employee/{dept}/{id}")
Patient getEmployee(@PathParam("dept")Long dept, @PathParam("id")Long id) ;

vs ?category+instance

@GET
@Path("/employee")
Patient getEmployee(@QueryParam("dept")Long dept, @QueryParam("id")Long id) ;

No creo que haya una convención estándar de hacerlo. ¿Esta ahí? Sin embargo, me gustaría saber cómo las personas usan PathParam vs QueryParam para diferenciar su información como lo ejemplifiqué anteriormente. También me encantaría escuchar la razón detrás de la práctica.

Answer 1

1. @QueryParam puede usarse convenientemente con la anotación del valor predeterminado para que pueda evitar una excepción de puntero nulo si no se pasa ningún parámetro de consulta.

Cuando desee analizar los parámetros de consulta de una solicitud GET, simplemente puede definir el parámetro respectivo al método que manejará la solicitud GET y anotarlos con la anotación @QueryParam

2. @PathParam extrae los valores de URI y coincide con @Path . Y por lo tanto obtiene el parámetro de entrada. 2.1 @PathParam puede ser más de uno y se establece en argumentos de métodos

   @Path("/rest")
   public class Abc {
   @GET
   @Path("/msg/{p0}/{p1}")
   @Produces("text/plain")
   public String add(@PathParam("p0") Integer param1, @PathParam("p1") Integer param2 )
   {
   return String.valueOf(param1+param2);
   }
   }

En el ejemplo anterior,
http://localhost:8080/Restr/rest/msg/{p0}/{p1} ,
param1 coincide con param1 y p1 coincide con param2 . Así que para la URI
http://localhost:8080/Restr/rest/msg/4/6 ,
Obtenemos el resultado 10 .

En el Servicio REST, JAX-RS proporciona @QueryParam y @FormParam ambos para aceptar datos de la solicitud HTTP. Un formulario HTTP puede ser enviado por diferentes métodos como GET y POST.

@QueryParam : Acepta la solicitud GET y lee los datos de la cadena de consulta.

@FormParam : Acepta la solicitud POST y recupera datos de un formulario HTML o cualquier solicitud de los medios

Answer 2

Como notó theon, REST no es un estándar. Sin embargo, si está buscando implementar una convención de URI basada en estándares, puede considerar la convención de URI oData . Ver 4 ha sido aprobado como un estándar de OASIS y existen bibliotecas para oData para varios idiomas, incluyendo Java a través de Apache Olingo . No deje que el hecho de que sea un producto de Microsoft lo desanime, ya que también cuenta con el apoyo de otros jugadores de la industria , que incluyen Red Hat, Citrix, IBM, Blackberry, Drupal, Facebook de Netflix y SAP.

Más adoptantes se enumeran aquí

Answer 3

Creo que si el parámetro identifica una entidad específica, debería usar una variable de ruta. Por ejemplo, para obtener todas las publicaciones en mi blog solicito

GET: myserver.com/myblog/posts

para obtener el post con id = 123, te lo pido

GET: myserver.com/myblog/posts/123

pero para filtrar mi lista de publicaciones y obtener todas las publicaciones desde el 1 de enero de 2013, solicitaría

GET: myserver.com/myblog/posts?since=2013-01-01

En el primer ejemplo, "publicaciones" identifica una entidad específica (la colección completa de publicaciones de blog). En el segundo ejemplo, "123" también representa una entidad específica (una sola publicación de blog). Pero en el último ejemplo, el parámetro "desde = 2013-01-01" es una solicitud para filtrar la colección de publicaciones, no una entidad específica. Paginación y ordenación sería otro buen ejemplo, es decir

GET: myserver.com/myblog/posts?page=2&order=backward

Espero que ayude. :-)

Answer 4

En pocas palabras,

@Pathparam funciona para el valor que pasa a través de los recursos y la cadena de consulta

• / usuario / 1
• / usuario? id = 1

@Queryparam funciona solo para el valor que pasa la cadena de consulta

• / usuario? id = 1

Answer 5

Es posible que REST no sea un estándar como tal, pero leer sobre la documentación general de REST y las publicaciones del blog debería proporcionarle algunas pautas para una buena manera de estructurar las URL de API. La mayoría de las API de descanso tienden a tener solo nombres de recursos e identificadores de recursos en la ruta. Como:

/departments/{dept}/employees/{id}

Algunas API REST usan cadenas de consulta para el filtrado, la paginación y la clasificación, pero como REST no es un estándar estricto, recomiendo revisar algunas API REST como github y y ver qué podría funcionar bien para su caso de uso.

Recomiendo poner cualquier parámetro requerido en la ruta, y cualquier parámetro opcional debe ser un parámetro de cadena de consulta. Si los parámetros opcionales se colocan en la URL, se volverán muy complicados al intentar escribir controladores de URL que coincidan con diferentes combinaciones.

Answer 6

Es una pregunta muy interesante.

Puede usar ambos, no hay ninguna regla estricta sobre este tema, pero el uso de las variables de ruta URI tiene algunas ventajas:

• Caché : la mayoría de los servicios de caché web en Internet no almacenan en caché la solicitud GET cuando contienen parámetros de consulta. Lo hacen porque hay muchos sistemas RPC que usan solicitudes GET para cambiar los datos en el servidor (¡falla! ¡Get debe ser un método seguro)

Pero si usa variables de ruta, todos estos servicios pueden almacenar en caché sus solicitudes GET.

• Jerarquía : las variables de ruta pueden representar jerarquía: / Ciudad / Calle / Lugar

Le da al usuario más información sobre la estructura de los datos.

Pero si sus datos no tienen ninguna relación jerárquica, aún puede usar las variables de ruta, usando coma o punto y coma:

/ Ciudad / longitud, latitud

Como regla general, use una coma cuando el orden de los parámetros es importante, use punto y coma cuando el orden no importa:

/ IconGenerator / rojo; azul; verde

Aparte de esas razones, hay algunos casos en los que es muy común utilizar variables de cadena de consulta:

• Cuando necesite que el navegador coloque automáticamente las variables de formulario HTML en el URI
• Cuando se trata de algoritmo. Por ejemplo, el motor de Google utiliza cadenas de consulta:

http: // www.google.com/search?q=rest

En resumen, no hay ninguna razón importante para usar uno de estos métodos, pero siempre que pueda, use las variables URI.

Answer 7

Esto es lo que hago.

Si existe un escenario para recuperar un registro basado en la identificación, por ejemplo, necesita obtener los detalles del empleado cuya identificación es 15, entonces puede tener recursos con @PathParam.

GET /employee/{id}

Si hay un escenario en el que necesita obtener los detalles de todos los empleados pero solo 10 a la vez, puede usar la consulta param.

GET /employee?start=1&size=10

Esto dice que la identificación del empleado que comienza 1 obtiene diez registros.

Para resumir, use @PathParam para la recuperación basada en id. Usuario @QueryParam para el filtro o si tiene alguna lista fija de opciones que el usuario puede pasar.

Answer 8

La razón es en realidad muy simple. Al usar un parámetro de consulta, puede tomar caracteres como "/" y su cliente no necesita codificarlos en HTML. Hay otras razones pero ese es un ejemplo simple. En cuanto a cuándo usar una variable de ruta. Diría que siempre que se trate de identificadores o si la variable de ruta es una dirección para una consulta.

Answer 9

Le doy un ejemplo a la parte inferior y cuándo usamos @Queryparam y @pathparam

Por ejemplo, estoy tomando un recurso es la clase carResource

Si desea que las entradas de su método de recursos sean manejables, use el tipo param como @pathaparam , si las entradas de su método de recursos deberían ser opcionales, entonces mantenga ese tipo de @QueryParam como @QueryParam param

@Path("/car")
class CarResource
{
@Get
@produces("text/plain")
@Path("/search/{carmodel}")
public String getCarSearch(@PathParam("carmodel")String model,@QueryParam("carcolor")String color) {
//logic for getting cars based on carmodel and color
-----
return cars
}
}

Para este resultado pase la solicitud.

req uri ://address:2020/carWeb/car/search/swift?carcolor=red

Si otorga una solicitud de este tipo, la respuesta proporcionará el modelo y el color del automóvil basado en

 req uri://address:2020/carWeb/car/search/swift

Si usted proporciona una solicitud como esta, el método de resolución mostrará solo un modelo basado en swift.

req://address:2020/carWeb/car/search?carcolor=red

Si realiza una donación como esta, obtendremos una excepción de ResourceNotFound porque en el vehículo, la clase I declara carmodel como @pathPram que es lo que debe y debe dar al carmodel como reQ uri. el color también pasará el req al recurso porque el color es @quetyParam es opcional en el req.

Answer 10

Personalmente utilicé el enfoque de "si tiene sentido para el usuario marcar una URL que incluya estos parámetros y luego usar PathParam".

Por ejemplo, si la URL de un perfil de usuario incluye algún parámetro de identificación de perfil, dado que el usuario puede marcarlo como favorito y / o enviarlo por correo electrónico, incluiría esa identificación de perfil como un parámetro de ruta. Además, otro aspecto importante de esto es que la página indicada por la URL que incluye la ruta param no cambia: el usuario configurará su perfil, lo guardará y, luego, es poco probable que cambie tanto a partir de ahí; esto significa que webcrawlers / search engines / browsers / etc pueden almacenar esta página en forma agradable en función de la ruta.

Si es probable que un parámetro pasado en la URL cambie el diseño / contenido de la página, lo usaría como queryparam. Por ejemplo, si la URL del perfil admite un parámetro que especifica si se muestra el correo electrónico del usuario o no, consideraría que es un parámetro de consulta. (Sé que podría decirse que el &noemail=1 o cualquier parámetro que sea puede usarse como parámetro de ruta y genera 2 páginas separadas, una con el correo electrónico y otra sin él), pero lógicamente no es el caso: sigue siendo la misma página con o sin ciertos atributos mostrados.

Espero que esto ayude, aprecio que la explicación sea un poco borrosa :)

Answer 11

Puede admitir tanto parámetros de consulta como parámetros de ruta, por ejemplo, en el caso de la agregación de recursos, cuando la recopilación de sub-recursos tiene sentido por sí sola.

/departments/{id}/employees
/employees?dept=id

Los parámetros de consulta pueden admitir subconjuntos jerárquicos y no jerárquicos; Los parámetros de ruta son solo jerárquicos.

Los recursos pueden exhibir múltiples jerarquías. Admita rutas cortas si va a consultar subcolecciones amplias que cruzan límites jerárquicos.

/inventory?make=toyota&model=corolla
/inventory?year=2014

Utilice los parámetros de consulta para combinar jerarquías ortogonales.

/inventory/makes/toyota/models/corolla?year=2014
/inventory/years/2014?make=toyota&model=corolla
/inventory?make=toyota&model=corolla&year=2014

Use solo parámetros de ruta en el caso de la composición, cuando un recurso no tiene sentido divorciado de su padre y la colección global de todos los hijos no es un recurso útil en sí mismo.

/words/{id}/definitions
/definitions?word=id // not useful

Answer 12

Puede utilizar los parámetros de consulta para el filtrado y los parámetros de ruta para la agrupación. El siguiente enlace tiene buena información sobre esto Cuándo usar pathParams o QueryParams

Answer 13

De Wikipedia: Uniform Resource Locator

Una ruta , que contiene datos, generalmente organizados en forma jerárquica , que aparece como una secuencia de segmentos separados por barras.

Una consulta opcional , separada de la parte anterior por un signo de interrogación (?), Que contiene una cadena de consulta de datos no jerárquicos .

- De acuerdo con el diseño conceptual de la URL, podríamos implementar un PathParam para los componentes de datos / directivas / localizadores jerárquicos, o implementar un QueryParam cuando los datos no son jerárquicos. Esto tiene sentido porque las rutas están naturalmente ordenadas, mientras que las consultas contienen variables que pueden ordenarse arbitrariamente (pares de valores / variables no ordenados).

Un comentarista anterior escribió,

Creo que si el parámetro identifica una entidad específica, debería usar una variable de ruta.

Otro escribió,

Utilice @PathParam para la recuperación basada en id. Usuario @QueryParam para el filtro o si tiene alguna lista fija de opciones que el usuario puede pasar.

Otro,

Recomiendo poner cualquier parámetro requerido en la ruta, y cualquier parámetro opcional debe ser un parámetro de cadena de consulta.

- Sin embargo, ¡se podría implementar un sistema flexible y no jerárquico para identificar entidades específicas! ¡Uno podría tener múltiples índices únicos en una tabla SQL, y permitir que las entidades se identifiquen utilizando cualquier combinación de campos que comprenda un índice único! Se pueden usar diferentes combinaciones (quizás también ordenadas de manera diferente), para los enlaces de varias entidades relacionadas (referentes). En este caso, podríamos estar tratando con datos no jerárquicos, utilizados para identificar entidades individuales, o en otros casos, puede que solo especifiquemos ciertas variables / campos (ciertos componentes de índices únicos) y recuperemos una lista / conjunto de registros. En tales casos, podría ser más fácil, más lógico y razonable implementar las URL como QueryParams.

¿Podría una larga cadena hexadecimal diluir / disminuir el valor de las palabras clave en el resto de la ruta? Podría valer la pena considerar las posibles implicaciones de SEO de colocar variables / valores en la ruta, o en la consulta , y las implicaciones de la interfaz humana de si queremos que los usuarios puedan atravesar / explorar la jerarquía de URL editando el contenido de la barra de direcciones ¡Mi página 404 No encontrada usa variables SSI para redireccionar automáticamente las URL dañadas a sus padres! Los robots de búsqueda también pueden atravesar la jerarquía del camino. Por otro lado, personalmente, cuando comparto las URL en las redes sociales, elimino manualmente cualquier identificador único privado, generalmente truncando la consulta de la URL, dejando solo la ruta: en este caso, hay alguna utilidad para colocar identificadores únicos en la ruta en lugar de en la consulta. Si queremos facilitar el uso de componentes de ruta como una interfaz de usuario simple, quizás dependamos de si los datos / componentes son legibles o no. La cuestión de la legibilidad humana se relaciona de alguna manera con la cuestión de la jerarquía: a menudo, los datos que pueden expresarse como palabras clave legibles también son jerárquicas; mientras que los datos jerárquicos a menudo se pueden expresar como palabras clave legibles por humanos. (Los motores de búsqueda podrían definirse como un aumento del uso de las URL como interfaz de usuario). Es posible que las jerarquías de palabras clave o directivas no estén estrictamente ordenadas, pero generalmente están lo suficientemente cerca como para que podamos cubrir casos alternativos en la ruta y etiquetar uno. Opción como el caso "canónico" .

Fundamentalmente, podemos responder a varios tipos de preguntas con la URL para cada solicitud:

1. ¿Qué tipo de registro / cosa estamos solicitando / sirviendo?
2. ¿En cuál (es) estamos interesados?
3. ¿Cómo queremos presentar la información / registros?

Q1 es casi seguramente mejor cubierto por la ruta, o por PathParams. Q3 (que probablemente se controla a través de un conjunto de parámetros opcionales y valores predeterminados ordenados arbitrariamente); es casi seguro que está cubierto por QueryParams. P2: Depende ...