En una prueba reciente, mi teléfono pudo descargar a 2172 kbps y cargar a 398 kbps, pero tuvo un tiempo de ida y vuelta de 3414 ms.
Eso coincide con mi experiencia con las solicitudes móviles en general; es probable que la latencia sea el factor dominante cuando se intenta entregar datos de manera eficiente a un dispositivo. Las preocupaciones secundarias incluyen el consumo de energía de mantener una radio activa con solicitudes frecuentes o la alta tasa de pérdida de la red. El ancho de banda disponible es limitado, pero creo que suele ser una preocupación menos importante.
Consideremos lo que ese tipo de número podría significar. Si hice un par de solicitudes secuenciales que requieren un ancho de banda insignificante, mi teléfono necesitaría esperar alrededor de 6.8 segundos para finalizar. En ese tiempo, podría haber enviado una sola solicitud y descargado al menos 927kB de datos (2172kbps para 3414ms).
Si solo nos preocupa el tiempo de tránsito, no voy a considerar una carga útil “grande” hasta que sea de al menos 1 mB.
Siendo realistas, también quiero asegurarme de que la solicitud finalice y contar con que la red permanezca disponible durante casi 7 segundos podría ser un problema, por lo que podría tratar de dividir esa carga útil en múltiples solicitudes simultáneas que podrían volverse a intentar individualmente o permitir una descarga parcialmente completa para ser reanudado
- ¿Cómo se estima el costo y el tiempo necesarios para desarrollar un juego / aplicación?
- Cómo desarrollar un back-end para una aplicación móvil
- ¿Cuál es la mejor agencia de desarrollo de aplicaciones móviles de Windows en Montreal?
- ¿Cuánto se necesitará para la externalización del desarrollo de aplicaciones?
- ¿Cómo crear una aplicación exitosa sin experiencia en la creación de aplicaciones? Mi idea puede ser un poco compleja. ¿Por dónde empiezo y a quién puedo recurrir para obtener ayuda?
Dependiendo de los usuarios, esta API está sirviendo al plan de datos del usuario final también podría ser una preocupación. Algunos usuarios pagan por kb, algunos tienen límites mensuales, de cualquier manera no quiero enviar demasiados datos, pero eso es un problema independientemente de si uso una solicitud grande o muchas más pequeñas.
Del mismo modo, quiero diseñar una API que no requiera (o aliente) encuestas u otra comunicación frecuente o de lo contrario los clientes que consuman esta API probablemente mantendrán activas las radios de sus dispositivos todo el tiempo, lo que puede ser una pérdida significativa de energía.
Finalmente, generalmente prefiero las solicitudes monolíticas a muchas solicitudes pequeñas porque eso facilita la definición de cada solicitud como una transacción que se aplica por completo o se revierte. De esa forma, mis clientes no se encuentran con un estado en el que algunas de sus muchas solicitudes pequeñas tuvieron éxito mientras que otras fallaron y ahora tienen una copia local inconsistente de los datos que mi API proporcionó.
Por ejemplo, es mejor para las relaciones de carga lateral que hacer una solicitud para cada tipo de recurso y terminar con una vista más reciente de los objetos principales que sus hijos.
Querrá usar ambos, dependiendo de la situación y los datos con los que está trabajando.
