Terminología
Todo producto termina armando su vocabulario. Esta página dice qué significa el nuestro, y por qué elegimos estas palabras y no otras.
Simulación
Una simulación es una copia en funcionamiento de un servicio: vive en su propia URL y responde como el original. Decimos simulación y no mock a propósito. Un mock es una respuesta falsa cableada dentro de un test. Una simulación se comporta: genera datos válidos desde tus esquemas, valida lo que le mandas, inyecta latencia y errores, puede reenviar al servicio real y caer al mock cuando está caído, y guarda estado donde el servicio real lo guardaría. El caso más claro es un backend resiliente corriendo un escenario: un pago que autorizas ahora, capturas después y reembolsas la semana que viene es una conversación con estado, no una respuesta fija. Sim es la misma palabra, más corta; te la vas a encontrar en la app y en las URLs.
Spec
El documento OpenAPI que describe una API. La palabra es de la industria, no nuestra, y la dejamos así. La spec es la fuente de verdad acá: todo lo que sirve una simulación sale de ella, así que actualizar la spec es como cambias la simulación.
Servicio
Una API dentro de una simulación. Una simulación puede servir varios servicios lado a lado, igual que tu sistema en producción habla con varias dependencias; una sim de app es exactamente esa composición. Se llama servicio porque eso es para tu código: la cosa a la que llama.
¿Un servicio puede llamar a otro servicio? Sí: un handler de codegen es código Go común, y el código Go común llama al endpoint que necesite, incluido el de un servicio hermano.
En un repo, cada servicio es un directorio de specs; el directorio services de la plantilla portable trae dos.
Endpoint
Un método y una ruta que un servicio responde. La mayoría se generan desde las operaciones de la spec. Los endpoints estáticos son la otra clase: un método, una ruta, un estado y un cuerpo fijos que escribes a mano, para esa respuesta exacta que un test necesita. Estáticos porque nunca varían.
Replay
Una respuesta real, grabada una vez y servida de vuelta a las solicitudes que coincidan. Replay porque no se inventa nada: lo que el upstream dijo de verdad se vuelve a reproducir. Tú configuras qué se graba y cómo se comparan las solicitudes; el tráfico reproducido aparece en el Historial como todo lo demás.
Consulta Grabar y ver replays.
Historial
El registro de cada llamada que respondió una simulación: método, ruta, estado, duración, y si la respuesta salió del mock o del upstream. Un nombre simple para una cosa simple.
Contexto
Valores con nombre que dirigen los datos generados. Sin uno, un campo generado es técnicamente válido y evidentemente falso; un contexto aporta los valores realistas, monedas, nombres de comercios, formatos de id. Acá también es donde Mockzilla se aparta de otros servicios de mock: tú controlas qué contiene una respuesta con unas pocas líneas de YAML. Sin IA, sin tokens, sin datasets pregenerados, sin ninguna otra magia, y la misma solicitud sigue recibiendo el mismo tipo de respuesta. En los backends resilientes un contexto son valores YAML que se usan en lugar de los que trae el proveedor. Contexto porque es el conocimiento alrededor que el generador lee cuando llena un campo.
Escenario
Una regla cuando/entonces en un backend resiliente: cuando una solicitud coincide con un disparador, un monto puntual, un número de tarjeta mágico, una palabra clave, entonces sigue un resultado guionado, un código de rechazo, un timeout, un caso enviado a revisión. Los proveedores hacen lo mismo con números de tarjeta de prueba; la diferencia es que acá el guion lo escribes tú. Escenario porque estás ensayando una situación, no devolviendo una respuesta fija.
Backend resiliente
Un reemplazo directo del sandbox de un proveedor de pago o de identidad. Los endpoints, las formas de las respuestas y los códigos de estado son los del proveedor, así que tu integración no cambia nada más que su URL base. Resiliente es la promesa que lleva el nombre: sigue en pie cuando el sandbox del proveedor está caído, limitado, o no puede producir la falla que necesitas probar.
Backend
Tu propia instancia de la API de un proveedor, y la palabra corta que usa la app para un backend resiliente. Apuntas tu integración ahí igual que al sandbox del proveedor. La diferencia es de quién es. Es tuyo: tú decides qué responde, y ningún otro test lo comparte.
Catálogo
Una colección curada de specs de APIs públicas, listas para desplegar como simulaciones. Navegas, eliges, obtienes una URL.
Portable y codegen
Las dos formas de entregar una simulación desde un repo. Portable empaqueta tus specs tal como están; portable porque el mismo paquete corre en cualquier lado, nuestra nube, tu laptop, Docker. El paquete es un archivo .mockz, y cualquier simulación se puede descargar como uno y correr en local. Codegen genera handlers de Go tipados desde tu spec para que tú les agregues lógica real; el nombre es lo que hace literalmente.
Consulta Simulaciones portables y Simulaciones codegen.