Estoy preparando una aplicación de una sola página que a veces se usaría en una conexión móvil lenta. Algunas de sus partes son bastante pesadas en términos de solicitudes de API (obteniendo diez recursos diferentes para una nueva pantalla).
Ahora, ¿es una buena idea combinar estos servicios con uno que proporcione todos los datos requeridos, pero no es tan "puro" en términos de los principios REST? ¿Se esperan ganancias significativas en el rendimiento?
Una de las ventajas de REST es la capacidad de almacenar en caché las solicitudes a través de cachés http tradicionales (suponiendo que se trata de solicitudes en caché).
Cuando tiene solicitudes individuales, más grandes, de uso menos frecuente y posiblemente diferentes (voy a buscar los elementos a,b,c,d esta vez y los artículos a,b,d,e la próxima vez) hará que sea más probable que la solicitud sea un error de caché. y caduque de un caché que pueda estar en algún lugar entre usted y la fuente.
Dados los dos conjuntos de solicitudes mencionados anteriormente, la segunda solicitud puede tener una tasa de 75% de caché hit y ser sustancialmente más rápida con solo e , en lugar de las cuatro cosas.
Tenga en cuenta que esto puede no ser inmediatamente evidente para las personas que lo utilizan, ya que la persona que hace el primer conjunto de solicitudes de falta de caché seguirá teniendo fallas en el caché.
Esto no quiere decir que sería ideal en una conexión de red móvil donde es menos probable que se obtengan visitas de caché no locales. Pero para los puntos calientes u otras situaciones de wifi, los aciertos de caché podrían ser mucho más útiles.
Mucho de esto, nuevamente, está sujeto a cómo funciona su aplicación. ¿Está pidiendo todos estos datos al inicio? ¿o estamos hablando de una carga de página donde las expectativas de tiempo de respuesta son diferentes?
Lo ideal sería probar esto para ver cómo se realiza su aplicación en una variedad de situaciones. Considere configurar una situación en la que haya vinculado su dispositivo móvil a una red wifi local que puede monitorear (que es solo el primer hit en google) y simulando una mala conexión a internet para ver cómo funcionan las cosas (o no) y cuál tiene el mejor rendimiento.
Su intuición es algo correcta, y en general es preferible hacer menos solicitudes; APIs gruesas tienden a ser mejores. Especialmente con la conectividad irregular donde puedes ver algo de trabajo y otros fallan en la creación de escenarios alternativos de pesadilla, ya que nada puede confiar en nada.
Hay una gran advertencia: puede volverse demasiado grueso y sus llamadas y respuestas se hinchan. Por ejemplo, podría tener sentido realizar una llamada importante cuando llegue por primera vez a una página y luego haga que las actualizaciones se realicen en porciones más pequeñas en lugar de forzar una actualización de la página grande cada vez que desee datos.
O, querrás hacerlo de ambas maneras con toda probabilidad.
Consulte este artículo del Blog de Dropbox Tech .
Allí describen detalladamente por qué y cómo implementaron exactamente la solución que propusiste para recuperar las miniaturas de todas tus fotos. Se debe decir que miden el rendimiento para ver si vale la pena y, aparentemente, lo es.
Breve resumen:
El sitio web de Dropbox tiene que cargar cientos de miniaturas. Debido a las limitaciones en algunos navegadores, no todas las miniaturas se cargan en paralelo (las solicitudes están en cola). Querían usar SPDY , pero no pudieron hacerlo porque algunas partes de su sistema aún no lo admiten. Al final, utilizaron solicitudes por lotes a través de HTTP, que devuelven múltiples miniaturas por respuesta en forma comprimida. La mejora general del tiempo de carga de la página fue del 40% según sus resultados.
En resumen: Su enfoque es un tanto correcto y podría beneficiarse de un Servicio de envoltura.
Este servicio combinará las llamadas únicas existentes en un método del lado del servicio. Haciendo eso combinando las llamadas del cliente al lado del servicio & utilizando todas las llamadas sencillas, atómicas y tranquilas que probablemente tenga en su lugar en este momento.
Por lo tanto, continuaría beneficiándose de REST como la capacidad de almacenar en caché las solicitudes.
Sin embargo, en el punto final, todo se reducirá al rendimiento de la infraestructura del servidor / servicio y al entorno del cliente que debería consumirlo.