Diseñar modelos de datos JSON eficientes es una de las decisiones más importantes cuando construyes aplicaciones móviles que consumen APIs. La clave está en negociar con el equipo de backend qué información viaja realmente entre cliente y servidor, evitando datos innecesarios que comprometen el performance y la seguridad.

¿Por qué importa el modelo de datos en la comunicación con APIs?

Cuando tu app mobile se comunica con un servidor, cada dato que entra y sale tiene un costo: ancho de banda, memoria, procesamiento y, sobre todo, tiempo de respuesta para el usuario.

El formato estándar para esta comunicación es JSON (JavaScript Object Notation), un formato breve, legible y ampliamente adoptado en la industria. Pero el formato no basta: lo que importa es qué metes dentro de ese JSON.

El modelo de datos se define en conjunto entre el equipo backend y el equipo front mobile. Tú, como cliente, tienes voz para decidir qué traer y qué omitir según lo que la vista realmente necesita mostrar.

¿Qué es un modelo de datos en una API? Es la estructura que define qué campos viajan entre el servidor y la aplicación. Se acuerda entre backend y front para que solo se envíe la información estrictamente necesaria.

¿Cómo identificar datos innecesarios en una respuesta JSON?

Imagina una vista simple: una lista de cursos con imagen, nombre y descripción. Si tu API responde con un objeto que incluye ID, nombre, imagen, descripción, rating, disponibilidad, información completa del profesor y un array con todos los estudiantes graduados, algo está mal.

Para esa vista solo necesitas tres cosas:

• El ID, para diferenciar cada curso por si haces cambios visuales.
• El nombre del curso.
• La URL de la imagen.

Todo lo demás sobra. No necesitas saber cuántos estudiantes graduados hay, ni los IDs de cada uno, ni quién es el profesor, ni si el curso está disponible. La regla es simple: basta con tener la información estrictamente necesaria para mostrar en la vista.

¿Cuándo sí necesitas más campos en el JSON?

Si la vista cambia y ahora muestras el detalle del curso con el nombre del profesor, entonces tiene sentido traer la información del docente. Pero incluso ahí, hay campos que jamás deben viajar.

La contraseña, por ejemplo, es un error garrafal. Nunca debes recibir ni enviar contraseñas a través de una API. Para autenticación existen mecanismos seguros como OAuth, que evitan exponer credenciales en las peticiones.

Del profesor, en una vista de detalle, probablemente solo necesitas el nombre y un ID para relacionarlo. El email, la foto, el rating personal o la descripción extensa pueden quedarse fuera si la interfaz no los pide.

¿Quién debe procesar los datos: el backend o el frontend?

Aquí viene una de las decisiones más importantes en el diseño de APIs para mobile: dónde recae la responsabilidad de procesar la información.

Supón que tu vista necesita mostrar el número de estudiantes graduados. Una opción es que el backend te envíe el array completo de estudiantes y tú los cuentes en el cliente. Suena fácil, pero es una mala práctica.

El procesador de un dispositivo móvil es limitado comparado con un servidor. Aunque los celulares cada vez son más potentes, las aplicaciones exigentes en performance y velocidad deben delegar el procesamiento pesado al backend.

La solución correcta es pedir al backend un campo ya calculado, por ejemplo graduatedStudentsCount con un valor entero como 230. Así evitas:

• Transferir un array enorme por la red.
• Iterar y contar elementos en el cliente.
• Consumir memoria y batería del dispositivo.

¿Por qué no procesar datos pesados en el cliente móvil? Porque el procesador y la memoria del dispositivo son limitados. Cualquier conteo, filtrado o transformación que pueda hacer el servidor debe hacerlo el servidor, no la app.

¿Cómo aplicar requerimientos funcionales al diseño del JSON?

Los requerimientos funcionales también moldean el modelo de datos. Si tu requerimiento dice que no debes mostrar cursos no disponibles, entonces esos cursos ni siquiera deberían llegar en la respuesta.

No tiene sentido recibir el campo de disponibilidad, leerlo y ocultar los cursos en el cliente. El filtro debe aplicarse en el backend. Lo mismo pasa con el rating o la descripción si la vista no los muestra: si no se renderizan, no deben viajar.

Esta lógica reduce drásticamente el tamaño de la respuesta. Un JSON inicial con decenas de líneas innecesarias puede reducirse a un objeto compacto con solo los campos que la interfaz consume.

¿Cómo negociar mejoras con el equipo de backend?

En la práctica vas a encontrarte con APIs muy bien orquestadas y con APIs terribles. Tu rol como desarrollador mobile incluye sugerir mejoras con argumentos técnicos: performance, seguridad, consumo de batería, experiencia de usuario.

Algunos puntos que puedes llevar a la conversación:

1. Eliminar campos sensibles como contraseñas y reemplazarlos por flujos seguros tipo OAuth.
2. Pedir contadores ya calculados en lugar de arrays completos.
3. Aplicar filtros en el servidor según los requerimientos funcionales.
4. Quitar campos que la vista no consume.

Trabajar en equipo con backend no es imponer, es construir un contrato de datos que beneficie a ambos lados y, sobre todo, al usuario final.

Conceptos y habilidades que aparecen en la clase

El formato JSON se presenta como el estándar de comunicación entre cliente y servidor por su simplicidad y legibilidad [0:35]. El concepto de modelo de datos aparece como un acuerdo entre backend y front sobre qué campos viajan en cada petición [0:10].

La idea de omitir datos innecesarios se ejemplifica con una lista de cursos donde solo se necesitan ID, nombre e imagen [1:25]. La advertencia sobre nunca enviar contraseñas y la mención a OAuth como alternativa segura aparece como uno de los tips más fuertes [2:50].

La decisión de delegar procesamiento al backend, como contar estudiantes graduados con un campo graduatedStudentsCount con valor 230, ilustra cómo cuidar el performance móvil [4:05]. Finalmente, los requerimientos funcionales y no funcionales guían qué datos pedir según lo que la vista realmente necesita [5:40].

¿Te ha tocado pelear con APIs mal diseñadas? Cuéntame en los comentarios cómo resolviste la conversación con tu equipo de backend.