Modelos y rutas (MongoDB)

Sí o No

Jugadas 32

Crear copia

Sobre esta actividad

Análisis de modelos y rutas

Creada por

Verónica Mora Lezcano

Costa Rica

Descarga la versión para jugar en papel

Top 10 resultados

#	Jugador	Acierto	tiempo
1	Fabi 9 de Abril de 2026	% 85	03:06

¿Quieres aparecer en el Top 10 de este juego? Inicia sesión para identificarte.

Crea tu propio juego gratis desde nuestro creador de juegos

Compite contra tus amigos para ver quien consigue la mejor puntuación en esta actividad

Crear reto

Grammys a mejor canción/grabación

Educaplay Educational Resources

España

(126)

Responde si estas canciones ganaron el Grammy a Mejor canción o grabación del año (los generales, no cuentan los Grammys de categorías)
¿Está creado con Inteligencia Artificial?

Educaplay Educational Resources

España

(6164)

Imágenes, canciones... Ya nada es lo que parece. ¿Están hechas con IA o son reales?
Preguntas sobre futbol para niños

Telminator Boom

España

(95)

Un juego de preguntas y respuestas para niños sobre el fútbol. Deberán responder con ✅ o ❌ a una serie de afirmaciones relacionadas con este deporte.
OPEN UP 5 UNIT 3: THERE IS/ARE, THERE WAS, THERE WERE

karen blixen

España

(11)

Estudiamos el grammar de la Unidad
¿Es verdad?

Educaplay Educational Resources

España

(244)

Responde si las siguientes frases sobre cultura general son verdaderas o no.

		%
	Anónimo	%
		%
		%

Imprime tu juego

Modelos y rutas (MongoDB)


Modelos y rutas (MongoDB)Versión en línea Análisis de modelos y rutas por Verónica Mora Lezcano 1 Si se define un esquema con un campo requerido y no se proporciona al crear un documento, Mongoose lanzará una excepción que debe capturarse en el bloque catch. Sí No 2 Para probar el endpoint POST /productos, es suficiente con enviar un JSON válido y verificar que el código de respuesta sea 200. Sí No 3 Si todas las pruebas del backend pasan correctamente, se puede garantizar que el frontend también funcionará sin errores. Sí No 4 Al probar el backend, conviene también simular errores como envío de datos incompletos, IDs inválidos o conflictos, para asegurar que los mensajes de error sean claros. Sí No 5 Para obtener un empleado junto con los datos completos de sus certificaciones (no solo los IDs), es necesario usar .populate('certificaciones'). Sí No 6 Dado el esquema de Empleado con un campo direccion embebido, ¿es correcto modelar la dirección como un subdocumento sin _id propio? Sí No 7 Al desarrollar una API, es una buena práctica probar los endpoints con herramientas como Postman o Thunder Client antes de hacer la conexión con el frontend. Sí No 8 Cuando se prueba un formulario de registro, es suficiente con probar una sola combinación de datos válidos; probar casos inválidos es opcional. Sí No 9 Usar res.status(400).json({ error: error.message }) en un catch es suficiente para manejar cualquier tipo de error. Sí No 10 Si un empleado puede tener muchas certificaciones y una certificación puede ser compartida por varios empleados, ¿es mejor usar referencia (ObjectId) en lugar de embebido? Sí No 11 En una ruta PUT para actualizar un empleado, ¿es obligatorio enviar todos los campos del modelo para evitar perder información? Sí No 12 En una ruta que recibe un id como parámetro, es buena práctica verificar si ese ID tiene un formato válido de MongoDB antes de buscar en la base de datos. Sí No 13 En un endpoint que agrega una certificación a un empleado, es suficiente recibir correo y certificacionId en el body; no es necesario verificar que la certificación exista previamente. Sí No

Puedes integrar el juego en un LMS compatible con LTI 1.1 o LTI 1.3 como Canvas, Moodle, o Blackboard. De esta manera podrás guardar las puntuaciones automáticamente en el libro de calificaciones de esa plataforma.

Modelos y rutas (MongoDB)

Sí o No

Sobre esta actividad

Creada por

Descarga la versión para jugar en papel

Top juegos

Sí o No

Grammys a mejor canción/grabación

Sí o No

¿Está creado con Inteligencia Artificial?

Sí o No

Preguntas sobre futbol para niños

Sí o No

OPEN UP 5 UNIT 3: THERE IS/ARE, THERE WAS, THERE WERE

Sí o No

¿Es verdad?

Modelos y rutas (MongoDB)Versión en línea

por Verónica Mora Lezcano

Si se define un esquema con un campo requerido y no se proporciona al crear un documento, Mongoose lanzará una excepción que debe capturarse en el bloque catch.

Para probar el endpoint POST /productos, es suficiente con enviar un JSON válido y verificar que el código de respuesta sea 200.

Si todas las pruebas del backend pasan correctamente, se puede garantizar que el frontend también funcionará sin errores.

Al probar el backend, conviene también simular errores como envío de datos incompletos, IDs inválidos o conflictos, para asegurar que los mensajes de error sean claros.

Para obtener un empleado junto con los datos completos de sus certificaciones (no solo los IDs), es necesario usar .populate('certificaciones').

Dado el esquema de Empleado con un campo direccion embebido, ¿es correcto modelar la dirección como un subdocumento sin _id propio?

Al desarrollar una API, es una buena práctica probar los endpoints con herramientas como Postman o Thunder Client antes de hacer la conexión con el frontend.

Cuando se prueba un formulario de registro, es suficiente con probar una sola combinación de datos válidos; probar casos inválidos es opcional.

Usar res.status(400).json({ error: error.message }) en un catch es suficiente para manejar cualquier tipo de error.

Si un empleado puede tener muchas certificaciones y una certificación puede ser compartida por varios empleados, ¿es mejor usar referencia (ObjectId) en lugar de embebido?

En una ruta PUT para actualizar un empleado, ¿es obligatorio enviar todos los campos del modelo para evitar perder información?

En una ruta que recibe un id como parámetro, es buena práctica verificar si ese ID tiene un formato válido de MongoDB antes de buscar en la base de datos.

En un endpoint que agrega una certificación a un empleado, es suficiente recibir correo y certificacionId en el body; no es necesario verificar que la certificación exista previamente.