Antes de empezar. Tienes una API publicada y una colección de peticiones. Hoy comprobarás que la versión pública conserva el contrato que funciona en local.
Se explica
25 minutos · explicación y demostración
Un contrato de API especifica qué puede solicitar un programa consumidor y qué obtendrá a cambio: método, ruta, campos y códigos de estado HTTP. Esas respuestas ya están implementadas en Servidor. En esta sesión se verifica que la versión publicada cumple el mismo contrato que la local, sin reimplementar sus controladores.
El consumidor puede ser Bruno, una prueba o un navegador. Para detectar un cambio incompatible no hace falta haber programado todavía una interfaz. El cliente completo con fetch y CORS se trabajará después de las sesiones 33–34 de Servidor, en Intermodular 18. Ahora utilizamos la colección que ya conoce el grupo.
La URL base determina el destino, no el contrato. La ruta /tareas debe mantener su denominación en el entorno local y en producción. El prefijo de versión /api/v1 se introduce en Servidor 32 y no procede incorporarlo antes por analogía con otras fuentes. Un código 404 puede indicar una ruta incorrecta aunque el proceso haya arrancado sin incidencias.
La demostración consiste en enviar la misma petición a dos entornos, comparar sus estados y campos y localizar el commit que produjo la respuesta pública. El resultado se documenta una vez y sirve a los dos módulos.
Se trabaja
140 minutos · trabajo guiado sobre el producto compartido
Bloque A · Preparar dos entornos de la misma colección
- Abre la colección de Servidor. Conserva sus peticiones; crea los entornos
localyproduccioncon una variablebaseUrlen cada uno. - Local usa
http://localhost:8080; producción usa la URL HTTPS de Intermodular 8. Retira la barra final si las rutas ya empiezan por/. - Cambia una petición a
{{baseUrl}}/tu-ruta-real. Elige una lectura de Servidor que ya funcione, no una ruta inventada. - Envía con cada entorno y anota estado, Content-Type y estructura del JSON. Los ids y datos pueden diferir; los tipos y nombres de campos deben cumplir el mismo contrato.
Bloque B · Escribir un caso comprobable
- En la descripción del contrato de la API añade una tabla con método, ruta, entrada mínima, estado esperado y campos de respuesta.
- Selecciona tres casos ya implementados: lectura correcta, recurso inexistente y entrada inválida. Copia ejemplos de tu API y elimina datos sensibles.
- Ejecuta cada caso en ambos entornos. Si difieren, comprueba primero versión desplegada y configuración; después abre una issue con petición y respuesta que reproduzcan el fallo.
- La corrección de implementación se realiza sobre el código compartido de Servidor. Intermodular conserva la prueba que detectó el desajuste y la PR que lo corrige.
Bloque C · Enlazar el producto desde el portfolio
- Actualiza la ficha existente con qué resuelve el producto, el repositorio y su estado actual. Utiliza el tema elegido al principio de Servidor.
- Añade un enlace al contrato y a una ruta GET pública de demostración. No necesitas construir hoy un formulario ni un cliente CRUD.
- Abre los enlaces desde la web publicada. Si el backend aún usa memoria, indica que los datos se reinician; esa limitación cambiará al publicar PostgreSQL.
- Lleva la modificación por issue, rama y PR. La persona revisora sigue los enlaces y reproduce uno de los casos del contrato.
Bloque D · Registrar la compatibilidad
Anota los dos entornos usados y el SHA del backend desplegado en las comprobaciones de la sesión. Enlaza la descripción del contrato de la API y las peticiones existentes, sin copiarlas a otra colección. Comprueba que una persona que llegue al README pueda localizar producto, versión y forma de probarlo.
Cierre
15 minutos · comprobación del resultado
Al terminar la sesión: La API publicada está contrastada con la colección: rutas, estados y datos coinciden con el contrato, y las diferencias encontradas están identificadas. Explica por qué terminar un despliegue no demuestra por sí solo que el producto funciona.