example - restful web services c#
Paginación en una aplicación web REST (12)
Actualmente estoy usando un esquema similar a este en mis aplicaciones ASP.NET MVC:
por ejemplo, http://application/products/by-date/page/2
específicamente es: http://application/products/Date/Ascending/3
Sin embargo, no estoy realmente contento de incluir la información de clasificación y clasificación en la ruta de esta manera.
La lista de elementos (productos en este caso) es mutable. es decir, la próxima vez que alguien vuelva a una URL que incluya parámetros de ordenamiento y clasificación, los resultados que obtuvieron podrían haber cambiado. Por lo tanto, se pierde la idea de http://application/products/Date/Ascending/3 como una URL única que apunta a un conjunto de productos definido e invariable.
Esta es una reformulación más genérica de esta pregunta (con la eliminación de las partes específicas de Rails)
No estoy seguro de cómo implementar la paginación en un recurso en una aplicación web RESTful. Suponiendo que tengo un recurso llamado products , ¿cuál de los siguientes cree que es el mejor enfoque y por qué?
1. Usando solo cadenas de consulta
p.ej. http://application/products?page=2&sort_by=date&sort_how=asc
El problema aquí es que no puedo usar el almacenamiento en caché de toda la página y que la URL no es muy limpia y fácil de recordar.
2. Usando las páginas como recursos y cadenas de consulta para ordenar
p.ej. http://application/products/page/2?sort_by=date&sort_how=asc
En este caso, el problema que se ve es que http://application/products/pages/1 no es un recurso único, ya que el uso de sort_by=price puede producir un resultado totalmente diferente y todavía no puedo usar el almacenamiento en caché de la página.
3. Usando páginas como recursos y un segmento de URL para ordenar
p.ej. http://application/products/by-date/page/2
Personalmente no veo ningún problema en el uso de este método, pero alguien me advirtió que esta no es una buena manera de hacerlo (no dio una razón, así que si sabe por qué no es recomendable, hágamelo saber)
Cualquier sugerencia, opinión, crítica es más que bienvenida. Gracias.
Buscando las mejores prácticas me encontré con este sitio:
http://www.restapitutorial.com
En la página de recursos hay un enlace para descargar un archivo .pdf que contiene las mejores prácticas REST completas sugeridas por el autor. En el que entre otras cosas hay una sección sobre paginación.
El autor sugiere agregar soporte tanto al uso de un encabezado de rango como a los parámetros de cadena de consulta.
Solicitud
Ejemplo de encabezado HTTP:
Range: items=0-24
Ejemplo de parámetros de cadena de consulta:
GET http://api.example.com/resources?offset=0&limit=25
Donde offset es el número de artículo inicial y el límite es el número máximo de elementos a devolver.
Respuesta
La respuesta debe incluir un encabezado de rango de contenido que indique cuántos elementos se devuelven y cuántos elementos totales existen aún por recuperar.
Ejemplos de encabezado HTTP:
Content-Range: items 0-24/66
Content-Range: items 40-65/*
En el .pdf hay otras sugerencias para casos más específicos.
Creo que el problema con la versión 3 es más un problema de "punto de vista": ¿ve la página como el recurso o los productos en la página?
Si ve la página como el recurso, es una solución perfecta, ya que la consulta para la página 2 siempre dará como resultado la página 2.
Pero si ve los productos en la página como el recurso, tiene el problema de que los productos en la página 2 podrían cambiar (productos antiguos eliminados, o lo que sea), en este caso, el URI no siempre devuelve los mismos recursos.
Por ejemplo, un cliente almacena un enlace a la página de la lista de productos X, la próxima vez que se abra el enlace, es posible que el producto en cuestión ya no esté en la página X.
Es extraño que nadie haya señalado que la Opción 3 tiene parámetros en un orden específico. http // application / products / Date / Descending / Name / Ascending / page / 2 y http // application / products / Name / Ascending / Date / Descending / page / 2
están apuntando al mismo recurso, pero tienen urls completamente diferentes.
Para mí, la opción 1 parece la más aceptable, ya que separa claramente "Lo que quiero" y "Cómo lo quiero" (incluso tiene un signo de interrogación entre ellos jajaja). El almacenamiento en caché de página completa se puede implementar utilizando la URL completa (todas las opciones sufrirán el mismo problema de todos modos).
Con el enfoque de Parámetros en URL, el único beneficio es una URL limpia. Aunque tiene que encontrar alguna forma de codificar parámetros y decodificarlos sin pérdidas. Por supuesto, puedes ir con URLencode / decode, pero hará que las URL sean feas otra vez :)
Estoy de acuerdo con Fionn, pero iré un paso más allá y diré que para mí la Página no es un recurso, es una propiedad de la solicitud. Eso me hace elegir la cadena de consulta opción 1 solamente. Simplemente se siente bien. Realmente me gusta cómo la API de Twitter está estructurada de manera tranquila. No demasiado simple, no demasiado complicado, bien documentado. Para bien o para mal, es mi diseño "ir a" cuando estoy en la cerca haciendo algo de una manera u otra.
HTTP tiene un gran encabezado de rango que también es adecuado para la paginación. Usted puede enviar
Range: pages=1
tener solo primera pagina. Eso puede obligarte a repensar qué es una página. Tal vez el cliente quiera una gama diferente de artículos. El encabezado de rango también funciona para declarar un pedido:
Range: products-by-date=2009_03_27-
para obtener todos los productos más nuevos que esa fecha o
Range: products-by-date=0-2009_11_30
para obtener todos los productos anteriores a esa fecha. ''0'' probablemente no sea la mejor solución, pero RFC parece querer algo para comenzar el rango. Puede haber implementados analizadores HTTP que no analizarían unidades = -range_end.
Si los encabezados no son una opción (aceptable), reconozco que la primera solución (todo en una cadena de consulta) es una forma de lidiar con las páginas. Pero, por favor, normalice las cadenas de consulta (ordenar (clave = valor) pares en orden alfabético). Esto resuelve el problema de diferenciación "? A = 1 & b = x" y "? B = x & a = 1".
He usado la solución 3 antes (escribo MUCHAS aplicaciones django). Y no creo que haya nada malo en ello. Es tan generoso como los otros dos (en caso de que necesite hacer un raspado en masa o similar) y se ve más limpio. Además, los usuarios pueden adivinar las URL (si es una aplicación pública), y a las personas les gusta poder ir directamente a donde quieren, y la adivinación de la URL se siente empoderadora.
La opción 1 parece la mejor, en la medida en que su aplicación ve la paginación como una técnica para producir una vista diferente del mismo recurso.
Dicho esto, el esquema de URL es relativamente insignificante. Si está diseñando su aplicación para que sea hypertext-driven (como todas las aplicaciones REST deben ser por definición), entonces su cliente no construirá ningún URI por sí solo. En su lugar, su aplicación proporcionará los enlaces al cliente y el cliente los seguirá.
Un tipo de enlace que su cliente puede proporcionar es un enlace de paginación.
El agradable efecto secundario de todo esto es que incluso si cambia de opinión sobre la estructura de URI de paginación e implementa algo totalmente diferente la próxima semana, sus clientes pueden seguir trabajando sin ninguna modificación.
Prefiero usar parámetros de consulta offset y límite.
offset : para el índice del artículo en la colección.
límite : para el recuento de artículos.
El cliente simplemente puede mantener la actualización de la siguiente manera
offset = offset + limit
para la siguiente página.
La ruta se considera el identificador de recursos. Y una página no es un recurso sino un subconjunto de la colección de recursos. Como la paginación es generalmente una solicitud GET, los parámetros de consulta son más adecuados para la paginación que para los encabezados.
Yo uso metamug . Tienen este configurable. Paginación en metamug de consulta selecto
Siempre he usado el estilo de la opción 1. El almacenamiento en caché no ha sido una preocupación, ya que los datos cambian con frecuencia de todas formas en mi caso. Si permite que el tamaño de la página sea configurable, los datos no se pueden almacenar en caché.
No encuentro el url difícil de recordar o sucio. Para mí esto es un buen uso de los parámetros de consulta. El recurso es claramente una lista de productos y los parámetros de consulta solo indican cómo desea que se muestre la lista: ordenada y en qué página.
Tiendo a estar de acuerdo con slf en que "página" no es realmente un recurso. Por otro lado, la opción 3 es más limpia, más fácil de leer, y el usuario la puede adivinar más fácilmente e incluso puede escribirla si es necesario. Estoy dividido entre las opciones 1 y 3, pero no veo ninguna razón para no usar la opción 3.
Además, aunque se ven bien, una desventaja de usar parámetros ocultos, como alguien mencionó, en lugar de cadenas de consulta o segmentos de URL es que el usuario no puede marcar o enlazar directamente a una página en particular. Eso puede o no ser un problema dependiendo de la aplicación, pero es algo que debe tener en cuenta.
Utilizo en mis proyectos las siguientes urls:
http://application/products?page=2&sort=+field1-field2
lo que significa que "dame la segunda página ordenada ascendiendo por field1 y luego descendiendo por field2". O si necesito aún más flexibilidad uso:
http://application/products?skip=20&limit=20&sort=+field1-field2