¿Es una buena idea fusionar múltiples solicitudes HTTP para ahorrar ancho de banda?

Estoy preparando una aplicación de una sola página que a veces se usaría a través de una conexión móvil lenta. Parte de su parte es bastante pesada en términos de solicitudes de API (obteniendo diez recursos diferentes para una nueva pantalla).

Ahora, ¿es una buena idea fusionar estos servicios con uno que proporcione todos los datos requeridos, pero que no sea tan "puro" en términos de principios REST? ¿Se esperan ganancias de rendimiento significativas?

Una de las ventajas de REST es la capacidad de almacenar en caché las solicitudes mediante cachés http tradicionales (suponiendo que se trata de solicitudes almacenables en caché).

Cuando tiene solicitudes individuales, más grandes, de uso menos frecuente y posiblemente diferentes (voy a buscar elementos a,b,c,desta vez y elementos la a,b,d,epróxima vez), es más probable que la solicitud sea una falta de caché y expire de un caché que puede estar sentado 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 aciertos de caché del 75% y ser sustancialmente más rápida para obtener solo e, en lugar de las cuatro cosas.

Tenga en cuenta que esto puede no ser evidente de inmediato para las personas que lo usan, ya que la persona que realiza el primer conjunto de solicitudes de pérdida de caché todavía tendrá las fallas de caché.

Esto no quiere decir que sería ideal en una conexión de red móvil en la que es menos probable que uno obtenga hits de caché no locales. Pero para los puntos calientes u otras situaciones wifi, los éxitos de caché podrían ser mucho más útiles.

Gran parte de esto, nuevamente, está sujeto a cómo funciona su aplicación. ¿Pide 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 pueda monitorear (que es solo el primer éxito en Google) y simule una mala conexión a Internet para ver cómo funcionan realmente las cosas (o no) y cuál tiene el mejor rendimiento.

Su intuición es algo correcta: en general, es preferible hacer menos solicitudes; Las API gruesas tienden a ser mejores. Especialmente con una conectividad irregular donde puedes ver algo de trabajo y algunos fallan al crear escenarios de pesadilla, ya que nada puede depender de nada.

Hay una gran advertencia: puede ser demasiado grueso y sus llamadas y respuestas se hinchan. Por ejemplo, podría tener sentido tener una gran llamada la primera vez que accedes a una página y luego recibir actualizaciones en pequeños fragmentos en lugar de forzar una actualización de página grande cada vez que deseas datos.

O bien, querrá hacerlo en ambos sentidos con toda probabilidad.

Revisa este artículo del blog de Dropbox Tech .

Allí describen en detalle por qué y cómo implementaron exactamente la solución que propuso para recuperar las miniaturas de todas sus imágenes. Debería decirse que sí 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 limitaciones en algunos navegadores, no todas las miniaturas se cargan en paralelo (las solicitudes se ponen 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 breve: su enfoque es algo correcto y podría beneficiarse de un servicio de envoltura.

Este servicio combinará llamadas individuales existentes en un método del lado del servicio. Para ello, combina las llamadas del cliente al servicio y utiliza todas las llamadas individuales, atómicas y relajantes que probablemente tengas en este momento.

Por lo tanto, continuaría teniendo los beneficios 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 de servicio / servidor y al entorno del cliente que debería consumirlo.