Ajustes del servicio
Cada servicio de una simulación tiene sus propios ajustes: adónde hace proxy, qué cachea, qué valida, y cómo se sirve su spec. Viven en Configuración del servicio, en la barra lateral.
Una página por servicio
La página configura un servicio a la vez. Elígelo en el desplegable de arriba; el ícono indica si es un conjunto de endpoints estáticos o una spec de OpenAPI.
Las dos clases comparten casi toda esta página. Upstream, Caché y YAML aplican a todos los servicios; Validación y Opciones de la spec existen solo para los servicios de OpenAPI, porque los dos necesitan una spec contra la cual trabajar. Un servicio estático tampoco tiene montaje que editar: su prefijo sale del primer segmento de ruta de sus endpoints.
El menú de la esquina administra el servicio en sí: Reemplazar archivo cambia la spec, Restablecer desde el catálogo repone una spec del catálogo, y Eliminar servicio lo borra. Eliminar un servicio estático borra cada endpoint bajo su prefijo.
Ruta de montaje
Junto al desplegable, un servicio de OpenAPI muestra su montaje como /<montaje>/*, editable ahí mismo. Letras minúsculas, dígitos, -, _ y /, sin barra al principio ni al final, hasta 32 caracteres; un montaje que ya tenga otro servicio se rechaza. Cambiarlo mueve cada endpoint del servicio al prefijo nuevo, así que quien llame tiene que seguirlo.
Upstream
Enciende Hacer proxy a un upstream y las solicitudes llegan primero a tu backend real; la simulación responde solo cuando el backend no lo hace.
Quién responde qué:
- El upstream responde bien: su respuesta se devuelve a quien llamó, sin tocar.
- El upstream no responde, se pasa de tiempo o devuelve un estado de error: responde en su lugar el mock generado.
- Los estados que coinciden con Fallar según el estado del upstream se saltan la caída al mock y llegan a quien llamó tal cual. Por defecto es
400-499salvo401y403: tu propia solicitud mal formada queda a la vista, mientras que una credencial faltante cae al mock. Coincidir por el cuerpo de la respuesta afina una regla para los backends que ponen los códigos de error dentro del cuerpo.
Cada respuesta dice de dónde salió: el encabezado X-Mockzilla-Source trae upstream, generated, cache o replay.
Los Encabezados agregados se adjuntan a cada solicitud enviada por proxy; un token de autenticación o un id de tenant va acá y no en cada cliente.
El Enrutamiento sticky del upstream ayuda cuando la caída al mock pasó a mitad de un flujo: después de que un cliente recibe una respuesta generada, sus solicitudes siguientes van directo al mock durante el tiempo indicado, para que una solicitud no mezcle estado real con estado generado.
El Timeout es cuánto esperar al backend, 5s salvo que lo cambies.
El upstream que pongas acá aplica a todo el servicio. Un endpoint suelto lo puede sobrescribir con otra URL, desde la pestaña Upstream de su propio panel; el resto de los endpoints sigue usando el upstream del servicio.
Consulta Endpoints y respuestas estáticas.
Caché
Cachear respuestas GET devuelve otra vez la primera respuesta para las solicitudes GET repetidas, en lugar de generarla o volver a pedirla cada vez. Solo se cachean las solicitudes GET, y en las repeticiones la respuesta cacheada le gana al upstream. Enciéndelo cuando los consumidores vuelvan a pedir lo mismo y que los datos cambien solo sea ruido.
Validación
Una spec OpenAPI es un contrato, y la pestaña Validación hace que la simulación lo haga cumplir.
- Validar solicitudes revisa los cuerpos entrantes y los parámetros de consulta y de ruta contra la spec. Una solicitud que no encaja recibe un 400 con detalles y nunca llega al upstream. Esta es la que hay que encender mientras construyes un cliente: el mock te avisa de una llamada mal formada en el mismo momento en que la haces.
- Validar respuestas revisa las respuestas a la salida; una respuesta que no encaja con la spec se vuelve un 500 con detalles. Para las respuestas generadas casi nunca hace falta. Se gana su lugar con un upstream: cada respuesta real se revisa contra la spec, lo que convierte a la simulación en un test de contrato del servicio de atrás. También atrapa un valor de contexto que rompe el esquema que llena.
- Detalles de error extendidos mete el esquema de referencia completo en los payloads de error; por defecto van livianos.
- Timeout de validación limita una sola llamada de validación, un segundo salvo que lo cambies, para que un esquema patológico no cuelgue las solicitudes.
Opciones de la spec
Estas opciones controlan cómo se carga y se sirve la spec. Importan sobre todo para las specs muy grandes.
- Cargar operaciones bajo demanda analiza cada operación en su primera solicitud en lugar de todas al arrancar. Arranque más rápido para las specs grandes, poca diferencia para las chicas.
- Simplificar el esquema recorta los esquemas desmedidos, descartando las ramas anyOf/oneOf/allOf de más. Encenderlo revela Limitar propiedades opcionales: cuántos campos opcionales conservan las respuestas generadas. Mínimo y máximo iguales dan una cantidad exacta; un rango elige al azar dentro de él.
Consulta Subir y actualizar una spec OpenAPI para saber cuándo una spec pesa lo suficiente como para necesitarlas.
La pestaña YAML
La misma configuración de las otras pestañas, mostrada en el YAML crudo del motor. Por ahora es de solo lectura; úsala para ver exactamente qué va a recibir la simulación desplegada.