Práctica del bloque 1 · Kiril Ferrer López

Cómo trabajar este bloque

Abre un ejercicio, lee la pregunta y responde en su cuadro de texto o selecciona una opción. El guardado es automático y local: no se envía a ningún servidor.

Las descargas, criterios detallados y materiales largos quedan dentro de Profundización opcional. Las dos series y el caso profesional sí son prácticas extensas para cuando quieras trabajar con más proceso.

Ver y revisar las respuestas guardadas

Ejercicios independientes

Son preguntas breves y autocontenidas. No requieren descargar archivos ni redactar un documento formal.

Pensar y responder en la web

No necesitas descargar nada ni preparar una entrega.

Pregunta central

¿Qué parte del registro corresponde a la URL, la ruta, la query, los headers y el body, y qué dato solo puedes inferir?

Información que necesitas

09:17:02  cliente=mobile-app/4.8
09:17:02  objetivo=https://archivo.intra.example/v1/expedientes/EXP-204?incluir=eventos&idioma=es
09:17:02  operación=actualizar parcialmente
09:17:02  x-request-id: req-8f21
09:17:02  content-type: application/json
09:17:02  authorization: Bearer [OCULTO]
09:17:02  payload-bytes=47
09:17:02  {"estado":"en_revision","notificar":false}
09:17:03  reintentos-configurados=0
09:17:03  respuesta-no-capturada

Para ordenar tu razonamiento

Separa las líneas en componentes HTTP sin copiar explicaciones de memoria.
Identifica las dos líneas que son configuración o contexto del cliente.
Explica en una frase qué información impide conocer el resultado final.

Tu razonamiento

Escribe lo que piensas. Se guarda automáticamente en este navegador.

Sin respuesta guardada.

Pistas opcionales

Pista 1 · Empieza por los límites

Localiza primero la URL completa y el objeto delimitado por llaves.
Todo lo demás debe clasificarse, no asumirse automáticamente como header.

Pista 2 · Lee la intención

La frase «actualizar parcialmente» permite razonar sobre el método, pero no constituye una línea HTTP observada.
Anota el nivel de certeza de esa elección.

Pista 3 · Revisa la frontera

Un parámetro tras el signo de interrogación pertenece a la query.
Un contador de reintentos es configuración del cliente, no contenido del mensaje enviado.

Profundización opcional

Reconstruir URL, método, ruta, query parameters, headers y body, y explicar el recorrido cliente-servidor sin recurrir todavía a FastAPI.

Contexto adicional

Trabaja únicamente con las evidencias del registro. Dos líneas son contexto operativo y no forman parte del mensaje HTTP.
Cuando una conclusión no pueda demostrarse, márcala como desconocida en lugar de inventarla.
Distingue siempre el dato observado de la interpretación que haces sobre él.

Cómo revisar tu respuesta

URL, ruta y query no aparecen mezcladas.
Los headers no se atribuyen al body y el JSON no se trata como parte de la URL.
Las dos líneas irrelevantes se reconocen y se justifica por qué no pertenecen al mensaje HTTP.
Las inferencias se diferencian explícitamente de los hechos observados.
El recorrido conserva una petición y una respuesta como mensajes distintos.

Evidencia, revisión y reinicio

Respuesta razonada guardada localmente en el navegador.
Tabla de anatomía y secuencia si se utiliza la plantilla opcional.

Revisión: con Codex, utilizando la evidencia y los criterios anteriores; no se publica una solución oficial.

Reinicio: Borrar la respuesta desde la tarjeta y volver a descargar una copia limpia de los materiales opcionales.

Material descargable opcional

Registro de soporteCopia descargable con el intercambio incompleto y las dos líneas de ruido.
Plantilla de análisisTabla vacía para registrar componente, evidencia, valor y grado de certeza.

Teoría que puedes consultar

Pensar y responder en la web

No necesitas descargar nada ni preparar una entrega.

Pregunta central

¿Qué código de estado escogerías en cada caso y qué tendría que hacer el cliente después de recibirlo?

Información que necesitas

A. La colección se obtiene correctamente y contiene 18 documentos.
B. Se crea un expediente nuevo con identificador asignado por el servidor.
C. El campo fecha_cierre contiene "mañana" y el contrato exige una fecha ISO.
D. El expediente EXP-999 no existe.
E. La referencia externa REF-77 ya pertenece a otro expediente.
F. La base de datos deja de responder durante una operación válida.

Para ordenar tu razonamiento

Clasifica primero cada situación como éxito, problema del cliente o fallo del servidor.
Elige un código concreto para A–F y justifícalo con una frase.
Señala un caso en el que otra respuesta también sería defendible bajo un supuesto distinto.

Pistas opcionales

Pista 1 · Decide primero la responsabilidad

Pregunta si una petición idéntica podría funcionar sin cambiar nada del servidor.
Después concreta el código dentro de la familia elegida.

Pista 2 · Conflicto no significa sintaxis inválida

Una representación puede estar bien formada y aun así chocar con el estado actual del sistema.

Profundización opcional

Seleccionar familias y códigos de estado adecuados, diferenciando éxito, error del cliente y error del servidor.

Contexto adicional

No basta con escribir un número: cada elección debe relacionarse con lo que ocurrió y con la acción que puede tomar el cliente.
Si dos códigos son defendibles, registra el supuesto que hace preferible uno de ellos.

Cómo revisar tu respuesta

No se utiliza 200 como respuesta universal.
Los errores provocados por datos del cliente no se clasifican como fallos internos.
La creación se distingue de una lectura satisfactoria cuando el servidor crea un recurso identificable.
La justificación describe comportamiento observable y no detalles de implementación.

Evidencia, revisión y reinicio

Selecciones razonadas guardadas localmente en el navegador.
Matriz de estados completada si se utiliza el material opcional.

Revisión: con Codex, utilizando la evidencia y los criterios anteriores; no se publica una solución oficial.

Reinicio: Borrar las selecciones desde la tarjeta y volver a descargar una matriz vacía cuando se necesite reiniciar.

Material descargable opcional

Matriz de incidentesPlantilla para código, familia, justificación, información de respuesta y alternativa descartada.

Teoría que puedes consultar

Unidad 1.1 · Códigos de estado

Pensar y responder en la web

No necesitas descargar nada ni preparar una entrega.

Pregunta central

¿Cómo representarías documentos, autores y préstamos como recursos sin convertir cada acción del enunciado en una ruta con un verbo?

Para ordenar tu razonamiento

Propón una ruta de colección y una ruta individual para cada recurso imprescindible.
Elige método y resultado esperado para abrir y finalizar un préstamo.
Explica qué ocurriría si el cliente repite la petición después de perder la respuesta.

Tu razonamiento

Escribe lo que piensas. Se guarda automáticamente en este navegador.

Sin respuesta guardada.

Pistas opcionales

Pista 1 · Sustantivos antes que rutas

Empieza por qué entidades reconoce el negocio y cuáles poseen identidad.
No conviertas cada frase de los requisitos en un endpoint.

Pista 2 · Piensa en la repetición

Para cada operación de escritura, imagina que la respuesta se pierde y el cliente repite exactamente la petición.

Profundización opcional

Diseñar un contrato HTTP coherente mediante recursos, rutas, métodos y estados, separando sustantivos de acciones.

Contexto adicional

Existen documentos, autores y préstamos con identificadores estables.
Un documento puede tener varios autores y puede estar disponible o prestado.
Los consumidores deben listar y filtrar documentos, consultar un documento, abrir un préstamo y registrar su finalización.
La referencia del préstamo la asigna el servidor.
Un cliente puede repetir una petición después de perder la respuesta por un timeout.

Decisiones abiertas

Cómo expresar la devolución o cierre del préstamo.
Si la relación documento-autor necesita operaciones propias en el alcance mínimo.
Qué filtros pertenecen a la colección de documentos.

Cómo revisar tu respuesta

Las rutas expresan recursos y no una colección arbitraria de verbos remotos.
Colección y elemento individual se distinguen de forma consistente.
La apertura de un préstamo no se presenta como idempotente sin una condición adicional explícita.
El contrato contempla recurso inexistente y conflicto de disponibilidad.
La decisión abierta se documenta sin fingir que existe una única respuesta universal.

Evidencia, revisión y reinicio

Respuesta de diseño guardada localmente en el navegador.
Contrato de operaciones y decisiones justificadas en la plantilla opcional.

Revisión: con Codex, utilizando la evidencia y los criterios anteriores; no se publica una solución oficial.

Reinicio: Borrar la respuesta desde la tarjeta y volver a descargar las plantillas originales antes de un nuevo intento.

Material descargable opcional

Requisitos del contratoEncargo completo, restricciones de identidad y preguntas abiertas.
Plantilla de operacionesTabla vacía de recurso, ruta, método, entrada, salida, estados y propiedades semánticas.

Teoría que puedes consultar

Pensar y responder en la web

No necesitas descargar nada ni preparar una entrega.

Pregunta central

¿Qué fragmentos no son JSON, cuáles sí son JSON pero incumplen el contrato y cuál aceptarías tal como está?

Información que necesitas

Fragmento A
{'id': 'doc-7', 'title': 'Informe', 'published': True,}

Fragmento B
{"id": 7, "title": "Informe", "tags": "api,http", "published": "false",
 "summary": null, "owner": {"id": "u-3", "name": "Ada"}}

Fragmento C
{"id": "doc-8", "title": "Acta", "tags": ["archivo", 2026],
 "published": false, "owner": null}

Fragmento D
{"id": "doc-9", "title": "Notas", "tags": [],
 "published": true, "owner": {"id": "u-8", "name": "Lin"}}

Para ordenar tu razonamiento

Clasifica A–D antes de intentar corregirlos.
Nombra el primer problema concreto que encuentres en cada fragmento.
Explica por qué null y un campo ausente no significan necesariamente lo mismo.

Pistas opcionales

Pista 1 · Dos preguntas distintas

Primero pregunta si un parser JSON podría leer el texto.
Después pregunta si el valor obtenido satisface el contrato.

Pista 2 · Revisa literales y comillas

JSON no utiliza exactamente los mismos literales ni las mismas reglas de comillas que Python.

Pista 3 · Recorre la estructura

No te detengas en los campos de primer nivel: revisa elementos de arrays y objetos anidados.

Profundización opcional

Distinguir errores de sintaxis JSON de desacuerdos semánticos con un contrato, atendiendo a tipos, arrays, ausencia y null.

Contexto adicional

Contrato de referencia: id es string requerido; title es string requerido; tags es array de strings; published es boolean; summary puede ser string o null; owner es un objeto con id y name.
La ausencia de summary está permitida. La ausencia de id, title u owner no lo está.
No corrijas automáticamente los datos: primero clasifica y explica cada fallo.

Cómo revisar tu respuesta

No se valida el contrato de un fragmento antes de resolver su sintaxis JSON.
String, número, boolean y array no se consideran intercambiables por su apariencia.
Null no se interpreta como ausencia.
Un fragmento válido y conforme se reconoce sin introducir cambios innecesarios.

Evidencia, revisión y reinicio

Clasificación de fragmentos guardada localmente en el navegador.
Diagnóstico por fragmento si se utiliza la plantilla opcional.

Revisión: con Codex, utilizando la evidencia y los criterios anteriores; no se publica una solución oficial.

Reinicio: Borrar las selecciones desde la tarjeta y descargar de nuevo los payloads y la plantilla sin modificar.

Material descargable opcional

Colección de payloadsFragmentos sin modificar, incluidos los que contienen sintaxis inválida.
Hoja de diagnósticoPlantilla para validez sintáctica, cumplimiento del contrato y cambio mínimo propuesto.

Teoría que puedes consultar

Pensar y responder en la web

No necesitas descargar nada ni preparar una entrega.

Pregunta central

Leyendo solo el documento OpenAPI, ¿qué petición válida harías para buscar obras y qué respuestas puede recibir un consumidor?

Documento OpenAPI

openapi: 3.1.0
info:
  title: Catálogo cultural local
  version: 1.0.0
servers:
  - url: https://catalogo.example.test/v1
paths:
  /obras:
    get:
      operationId: listWorks
      summary: Buscar obras del catálogo
      parameters:
        - name: q
          in: query
          required: false
          schema:
            type: string
            minLength: 2
        - name: tipo
          in: query
          required: false
          schema:
            type: string
            enum: [pintura, escultura, fotografia]
        - name: limite
          in: query
          required: false
          schema:
            type: integer
            minimum: 1
            maximum: 50
            default: 20
      responses:
        "200":
          description: Colección filtrada
          content:
            application/json:
              schema:
                $ref: "#/components/schemas/WorkCollection"
        "400":
          description: Parámetro de consulta inválido
          content:
            application/json:
              schema:
                $ref: "#/components/schemas/Problem"
  /obras/{work_id}:
    get:
      operationId: getWork
      summary: Consultar una obra
      parameters:
        - name: work_id
          in: path
          required: true
          schema:
            type: string
            pattern: "^wrk-[0-9]+$"
      responses:
        "200":
          description: Obra encontrada
          content:
            application/json:
              schema:
                $ref: "#/components/schemas/Work"
        "404":
          description: La obra no existe
          content:
            application/json:
              schema:
                $ref: "#/components/schemas/Problem"
components:
  schemas:
    Work:
      type: object
      required: [id, title, type]
      properties:
        id:
          type: string
        title:
          type: string
        type:
          type: string
          enum: [pintura, escultura, fotografia]
        author:
          type: [string, "null"]
        year:
          type: [integer, "null"]
    WorkCollection:
      type: object
      required: [items, total]
      properties:
        items:
          type: array
          items:
            $ref: "#/components/schemas/Work"
        total:
          type: integer
          minimum: 0
    Problem:
      type: object
      required: [code, message]
      properties:
        code:
          type: string
        message:
          type: string

Para ordenar tu razonamiento

Localiza la URL base, la ruta, el método y los parámetros disponibles.
Distingue qué parámetros son opcionales y qué límites tienen.
Describe una respuesta satisfactoria y un error siguiendo los schemas referenciados.

Tu razonamiento

Escribe lo que piensas. Se guarda automáticamente en este navegador.

Sin respuesta guardada.

Pistas opcionales

Pista 1 · Recorre el contrato en capas

Empieza por servers y paths; después baja a cada método, parameters y responses.
Deja components para cuando encuentres una referencia.

Pista 2 · Separa descripción y restricción

Una descripción explica intención; type, enum, minimum y required restringen valores.

Profundización opcional

Deducir entradas, salidas, obligatoriedad y errores directamente desde un documento OpenAPI 3.1.

Contexto adicional

El contrato contiene una consulta de colección y una consulta individual.
No se pide implementar un cliente ni memorizar toda la especificación OpenAPI.
Cada afirmación debe señalar el elemento del contrato que la respalda.

Cómo revisar tu respuesta

Los parámetros de path y query no se intercambian.
La obligatoriedad se obtiene de required y no de la intuición.
Las referencias $ref se siguen hasta el schema correspondiente.
La lectura funciona sin depender de Swagger UI.

Evidencia, revisión y reinicio

Lectura razonada guardada localmente en el navegador.
Cuestionario de contrato completado si se usa el material opcional.

Revisión: con Codex, utilizando la evidencia y los criterios anteriores; no se publica una solución oficial.

Reinicio: Borrar la respuesta desde la tarjeta y descargar otra copia del contrato y cuestionario originales.

Material descargable opcional

Contrato OpenAPIEspecificación local, reducida y válida para un catálogo cultural ficticio.
Cuestionario de lecturaPreguntas sobre operaciones, parámetros, schemas y respuestas.

Teoría que puedes consultar

Pensar y responder en la web

No necesitas descargar nada ni preparar una entrega.

Pregunta central

Si la primera respuesta se pierde y el cliente repite exactamente la petición, ¿qué operaciones son seguras, idempotentes o arriesgadas de reintentar?

Información que necesitas

1. GET /reservas/{id} — consulta una reserva y registra métricas de lectura.
2. HEAD /salas/{id}/disponibilidad — devuelve únicamente cabeceras.
3. POST /cargos — crea un cargo nuevo por cada petición aceptada.
4. PUT /usuarios/{id}/preferencias — sustituye todas las preferencias por el body.
5. DELETE /suscripciones/{id} — elimina la suscripción si existe.
6. PATCH /pedidos/{id} — añade 1 al contador de intentos.
7. POST /webhooks/entregas — registra la entrega; acepta una clave única de entrega.

Para ordenar tu razonamiento

Clasifica las siete operaciones en segura/no segura e idempotente/no idempotente.
Compara el estado tras una ejecución con el estado tras dos peticiones iguales.
Elige el caso más engañoso y explica la confusión habitual.

Pistas opcionales

Pista única · Compara el estado final

Para idempotencia, compara el estado relevante tras una ejecución con el estado tras varias peticiones idénticas.

Profundización opcional

Clasificar operaciones HTTP por seguridad e idempotencia y predecir el riesgo de repetirlas cuando la primera respuesta se pierde.

Contexto adicional

Clasifica la operación por su comportamiento prometido, no solo por el nombre del método.
Diferencia que una operación sea idempotente de que siempre tenga éxito o carezca de efectos secundarios.

Cómo revisar tu respuesta

Seguro e idempotente se evalúan como propiedades distintas.
Registrar métricas no invalida automáticamente la intención segura de una lectura.
La idempotencia no se confunde con obtener la misma representación o el mismo código en cada intento.
Los reintentos consideran el efecto de una primera ejecución cuya respuesta se perdió.

Evidencia, revisión y reinicio

Clasificaciones guardadas localmente en el navegador.
Justificación del efecto de repetición si se completa la tabla opcional.

Revisión: con Codex, utilizando la evidencia y los criterios anteriores; no se publica una solución oficial.

Reinicio: Borrar las selecciones desde la tarjeta y volver a descargar la tabla de operaciones original.

Material descargable opcional

Tabla de operacionesMatriz vacía para semántica, repetición, riesgo y política de reintento.

Teoría que puedes consultar

Unidad 1.1 · Semántica de métodos

Pensar y responder en la web

No necesitas descargar nada ni preparar una entrega.

Pregunta central

¿En qué orden deben ocurrir los pasos de una primera petición y cuáles podrían desaparecer cuando se reutiliza una conexión?

Información que necesitas

A · El cliente interpreta el JSON.
B · El servidor ejecuta la lógica.
C · El cliente resuelve el host.
D · El servidor envía la respuesta.
E · Se establece la conexión.
F · El cliente construye la petición.
G · El servidor recibe y analiza HTTP.
H · El cliente recibe la respuesta.
I · El cliente envía la petición.
J · El servidor serializa el resultado.

Para ordenar tu razonamiento

Ordena las tarjetas A–J para la primera traza.
Marca qué pasos pertenecen al cliente, la red o el servidor.
Explica qué cambia en la segunda traza y por qué.

Tu razonamiento

Escribe lo que piensas. Se guarda automáticamente en este navegador.

Sin respuesta guardada.

Pistas opcionales

Pista 1 · Identifica prerequisitos

Una conexión necesita un destino; el servidor necesita recibir datos antes de procesarlos.

Pista 2 · Cambia de perspectiva

Recorre la línea temporal primero desde el cliente y luego desde el servidor para detectar inversiones.

Profundización opcional

Ordenar resolución, conexión, petición, procesamiento, respuesta y representación distinguiendo red, HTTP, aplicación y datos.

Contexto adicional

Las tarjetas están deliberadamente desordenadas.
La segunda traza no repite todos los pasos de la primera.
No es necesario conocer paquetes TCP ni detalles criptográficos.

Cómo revisar tu respuesta

La lógica de aplicación no se ejecuta antes de que el servidor reciba la petición.
La serialización o interpretación del JSON no se confunde con el transporte.
La reutilización de conexión elimina pasos solo cuando la evidencia lo permite.
Petición y respuesta mantienen dirección y fronteras claras.

Evidencia, revisión y reinicio

Secuencia razonada guardada localmente en el navegador.
Lienzo de capas y puntos de fallo si se utilizan los materiales opcionales.

Revisión: con Codex, utilizando la evidencia y los criterios anteriores; no se publica una solución oficial.

Reinicio: Borrar la respuesta desde la tarjeta y descargar de nuevo las tarjetas y el lienzo originales.

Material descargable opcional

Tarjetas y trazasTarjetas recortables y dos observaciones de red simplificadas.
Lienzo de secuenciaPlantilla para ordenar pasos y asignar responsable.

Teoría que puedes consultar

Unidad 1.1 · Flujo completo de una interacción

Pensar y responder en la web

No necesitas descargar nada ni preparar una entrega.

Pregunta central

Mientras una tarea espera red o disco, ¿qué otra tarea podría avanzar y qué parte no se vuelve más rápida por usar async?

Información que necesitas

Tarea A: preparar petición (1) → esperar red (4) → validar respuesta (2)
Tarea B: calcular informe (5) → escribir archivo (3)
Tarea C: leer archivo (3) → transformar filas (2) → esperar confirmación remota (2)

Los números son unidades relativas de duración, no segundos medidos.

Para ordenar tu razonamiento

Clasifica cada fase como espera de I/O o trabajo activo de CPU.
Propón un orden concurrente posible sin ejecutar dos cálculos a la vez.
Explica con este caso la diferencia entre concurrencia y paralelismo.

Tu razonamiento

Escribe lo que piensas. Se guarda automáticamente en este navegador.

Sin respuesta guardada.

Pistas opcionales

Pista 1 · Colorea espera y trabajo

Usa dos categorías iniciales: la CPU trabaja o espera a un sistema externo.

Pista 2 · Rellena huecos

Cuando una tarea espera, busca otra fase lista para usar la CPU.

Pista 3 · Verifica la restricción

En este escenario no puedes dibujar dos cálculos activos en el mismo instante.

Profundización opcional

Reconocer esperas de I/O, trabajo de CPU y oportunidades de concurrencia sin confundirlas con paralelismo.

Contexto adicional

Una sola CPU lógica ejecuta trabajo de Python en cada instante del escenario.
Las esperas de red y disco no necesitan cálculo activo durante toda su duración.
El planificador solo puede cambiar de tarea en los puntos de cesión marcados como posibles.

Cómo revisar tu respuesta

Las esperas de I/O se distinguen del cálculo activo.
El cronograma no ejecuta dos tramos de CPU simultáneamente en una única CPU lógica.
La cesión se justifica por una espera o punto cooperativo, no por magia.
No se afirma que async acelere el cálculo del informe.

Evidencia, revisión y reinicio

Análisis temporal guardado localmente en el navegador.
Cronogramas anotados si se utiliza el material opcional.

Revisión: con Codex, utilizando la evidencia y los criterios anteriores; no se publica una solución oficial.

Reinicio: Borrar la respuesta desde la tarjeta y volver a descargar los cronogramas sin anotaciones.

Material descargable opcional

Cronogramas conceptualesTres tareas, plantilla secuencial y plantilla concurrente sin sintaxis Python.

Teoría que puedes consultar

Pensar y responder en la web

No necesitas descargar nada ni preparar una entrega.

Pregunta central

¿Qué cambios puede aceptar un consumidor existente sin modificarse y cuáles rompen peticiones o respuestas que antes eran válidas?

Diff OpenAPI

--- ex-b1-09-openapi-v1.yaml
+++ ex-b1-09-openapi-v1.1.yaml
@@ -1,29 +1,30 @@
 openapi: 3.1.0
 info:
   title: Records API
-  version: 1.0.0
+  version: 1.1.0
 paths:
-  /records/{record_id}:
+  /record/{id}:
     get:
       summary: Get a record
-      description: Returns one record.
+      description: Returns one record. Rate limiting may apply.
       operationId: getRecord
       parameters:
-        - name: record_id
+        - name: id
           in: path
           required: true
           schema:
-            type: integer
-            minimum: 1
+            type: string
       responses:
         "200":
-          description: Record found
+          description: Record found or absent
           content:
             application/json:
               schema:
-                $ref: "#/components/schemas/Record"
-        "404":
-          description: Record not found
+                oneOf:
+                  - $ref: "#/components/schemas/Record"
+                  - type: "null"
+        "429":
+          description: Too many requests
           content:
             application/json:
               schema:
                 $ref: "#/components/schemas/Problem"
@@ -32,12 +33,17 @@ components:
   schemas:
     Record:
       type: object
-      required: [id, title]
+      required: [id, title, owner_id]
       properties:
         id:
-          type: integer
+          type: string
         title:
           type: string
+        owner_id:
+          type: string
+        archived_at:
+          type: [string, "null"]
+          format: date-time
     Problem:
       type: object
       required: [code, message]

Para ordenar tu razonamiento

Clasifica cada cambio como compatible, dudoso o ruptura.
Explica qué consumidor se vería afectado en los dos cambios de mayor impacto.
Propón una transición breve para una ruptura confirmada.

Tu razonamiento

Escribe lo que piensas. Se guarda automáticamente en este navegador.

Sin respuesta guardada.

Pistas opcionales

Pista única · Piensa como un consumidor existente

Imagina una petición válida ayer y una respuesta que el cliente sabía interpretar ayer. Comprueba ambas contra el contrato propuesto.

Profundización opcional

Identificar cambios compatibles y rupturas en rutas, nombres, tipos, campos requeridos y respuestas.

Contexto adicional

Considera clientes que generan código desde OpenAPI y clientes que interpretan respuestas manualmente.
No todo cambio visible rompe necesariamente el contrato; explica quién podría verse afectado.

Cómo revisar tu respuesta

Se revisan rutas, parámetros, tipos, required y códigos de respuesta.
Añadir información opcional no se trata igual que exigir un campo nuevo.
El impacto se relaciona con consumidores concretos.
Las transiciones evitan mantener versiones paralelas sin necesidad demostrada.

Evidencia, revisión y reinicio

Revisión razonada guardada localmente en el navegador.
Informe de compatibilidad y transición si se utiliza la plantilla opcional.

Revisión: con Codex, utilizando la evidencia y los criterios anteriores; no se publica una solución oficial.

Reinicio: Borrar la respuesta desde la tarjeta y volver a descargar el diff y el informe vacíos.

Material descargable opcional

OpenAPI v1.0Documento OpenAPI 3.1 completo del contrato vigente.
OpenAPI v1.1 propuestoDocumento OpenAPI 3.1 completo del contrato propuesto.
Diff OpenAPIDiff unificado entre ambos documentos, con claves OAS reales.
Informe de compatibilidadPlantilla para impacto, consumidor afectado y transición.

Teoría que puedes consultar

Unidad 1.2 · El contrato como límite

Series

Prácticas extendidas y opcionales. Cada serie conserva una base común y una parte utiliza el resultado de la anterior.

Abrir práctica extendida: base común y 3 partes

Base común

El cliente informa de que la red funciona y otras operaciones contra el mismo host responden.
La captura contiene una petición completa y una respuesta HTTP.
El contrato declara un media type específico para la creación.
Cada conclusión debe enlazarse con una evidencia del paquete.

Paquete de trabajo

Ticket y tráfico capturadoIncidente, petición, respuesta y contexto operativo.
Documento OpenAPI acotadoDocumento OpenAPI 3.1 que describe la creación de expedientes.
Cuaderno de la serieCheckpoint vacío para conservar evidencias, hipótesis y decisiones entre partes.

Entorno, evidencia y reinicio

Entorno: Paquete descargable trabajado en un directorio separado del repositorio.

Cuaderno de la serie con hechos, hipótesis y decisiones.
Petición y respuesta reconstruidas, diagnóstico y propuesta contractual.

Revisión: con Codex, utilizando los artefactos y criterios de cada parte; no se publica una solución oficial.

Reinicio: Crear un directorio de trabajo nuevo y volver a descargar el ticket, el contrato y el cuaderno originales.

Parte 1 · Guiado alto

EX-B1-S01-01 · Reconstruir el intercambio

Ordenar las evidencias y producir una representación conceptual de petición y respuesta.

Qué debes hacer

Separa observaciones del ticket, captura HTTP y contrato.
Reconstruye método, URL, headers, body, estado y body de respuesta.
Señala cualquier dato que falte o esté redactado.
Anota qué evidencia respalda cada elemento.

Entrega esperada

Petición y respuesta reconstruidas.
Tabla evidencia → conclusión.

Criterios de aceptación

No se inventan headers o campos ausentes.
Petición y respuesta conservan sus fronteras.
Cada conclusión importante cita una línea o sección concreta.

Evidencia para revisión

Petición y respuesta reconstruidas.
Tabla que relaciona cada conclusión con su evidencia.

Reinicio de esta parte: Reiniciar desde una copia nueva del paquete y conservar el resultado como checkpoint independiente.

Pista 1 · Tres fuentes

No mezcles lo que dice el usuario con lo capturado en red ni con lo prometido por el contrato.

Pista 2 · Orden de lectura

Empieza por request line y status line; después añade headers y body a cada mensaje.

Parte 2 · Guiado moderado

EX-B1-S01-02 · Clasificar el fallo

Determinar si el problema pertenece al transporte, HTTP, JSON o contrato y descartar causas plausibles.

Qué debes hacer

Formula una hipótesis principal y al menos dos alternativas.
Comprueba cada hipótesis contra ticket, tráfico y OpenAPI.
Clasifica la capa en la que aparece la discrepancia.
Explica por qué dos causas plausibles no encajan con la evidencia.

Entrega esperada

Diagnóstico principal con nivel de confianza.
Dos descartes razonados.

Criterios de aceptación

El diagnóstico diferencia que HTTP haya respondido de que la operación haya sido aceptada.
La validez sintáctica del JSON se evalúa aparte de su conformidad contractual.
Los descartes utilizan evidencia y no intuiciones sobre frameworks.

Evidencia para revisión

Diagnóstico principal con nivel de confianza.
Dos hipótesis descartadas mediante evidencia.

Reinicio de esta parte: Volver al checkpoint de la parte 1 o reconstruirlo desde una copia limpia del paquete.

Pista · Compara observado y prometido

Busca la primera diferencia verificable entre el mensaje capturado y la operación descrita en OpenAPI.

Parte 3 · Guiado ligero

EX-B1-S01-03 · Proponer el contrato corregido

Rediseñar el comportamiento observable y explicar una transición compatible.

Qué debes hacer

Decide si debe cambiar el cliente, el contrato, el servidor o una combinación.
Describe el comportamiento corregido para éxito y error.
Propón una transición que contemple consumidores existentes.
Define criterios que permitirían verificar el cambio sin conocer la implementación.

Entrega esperada

Contrato corregido a nivel de diseño.
Nota de compatibilidad y transición.
Criterios observables de verificación.

Criterios de aceptación

La propuesta corrige la discrepancia diagnosticada.
La transición identifica al consumidor afectado.
Los criterios pueden comprobarse mediante mensajes HTTP.

Evidencia para revisión

Contrato corregido a nivel de diseño.
Nota de compatibilidad y criterios observables de verificación.

Reinicio de esta parte: Volver al checkpoint de la parte 2 y trabajar sobre una copia nueva del documento OpenAPI acotado.

Pista · Cambia lo mínimo necesario

No rediseñes toda la API si una frontera concreta explica el incidente.

Teoría que puedes consultar

Abrir práctica extendida: base común y 3 partes

Base común

La muestra contiene municipios, periodos e indicadores con unidades diferentes.
Los consumidores necesitan consultas filtradas y una exportación.
La colección debe paginarse y rechazar límites desproporcionados.
No se consumirá todavía una API pública ni se implementará FastAPI.

Paquete de trabajo

Muestra de indicadoresDataset sintético pequeño con dos indicadores, tres municipios y valores ausentes.
Necesidad y restriccionesDestinatarios, consultas necesarias, paginación y decisiones abiertas.
Plantilla OpenAPIEsqueleto deliberadamente incompleto para la tercera parte.

Entorno, evidencia y reinicio

Entorno: Dataset y plantillas descargables trabajados en un directorio separado del repositorio.

Inventario de recursos y representaciones.
Tabla de operaciones y documento OpenAPI acotado y autocontenido.

Revisión: con Codex, utilizando los artefactos y criterios de cada parte; no se publica una solución oficial.

Reinicio: Crear un directorio nuevo y volver a descargar la muestra, el brief y la plantilla OpenAPI originales.

Parte 1 · Guiado moderado

EX-B1-S02-01 · Del dato al recurso

Identificar recursos, representaciones e identificadores a partir de la muestra.

Qué debes hacer

Distingue entidades con identidad de valores observados y catálogos.
Propón una representación JSON para una observación y otra para una colección.
Registra cómo representarás un valor ausente sin inventarlo.
Describe dos relaciones entre los recursos propuestos.

Entrega esperada

Inventario de recursos e identificadores.
Dos representaciones JSON conceptuales.

Criterios de aceptación

La interfaz no se modela como una lista de verbos.
Municipio, indicador, periodo, valor y unidad no se confunden.
El valor ausente conserva su significado.

Evidencia para revisión

Inventario de recursos e identificadores.
Dos representaciones JSON conceptuales.

Reinicio de esta parte: Reiniciar desde copias nuevas del dataset y del brief y conservar el resultado como checkpoint.

Pista · Busca identidad y estabilidad

Un nombre visible puede cambiar; revisa qué códigos de la muestra pueden funcionar como identificadores.

Parte 2 · Guiado moderado

EX-B1-S02-02 · Rutas, filtros y errores

Diseñar operaciones de consulta y exportación sobre el modelo de recursos anterior.

Qué debes hacer

Define rutas y métodos para consultar colecciones y elementos.
Asigna filtros a path o query y justifica la elección.
Diseña paginación y un límite máximo observable.
Selecciona estados para recurso ausente, filtro inválido y solicitud demasiado amplia.
Decide cómo expresar la exportación sin introducir procesamiento asíncrono implementado.

Entrega esperada

Tabla de operaciones y parámetros.
Matriz de estados y condiciones.

Criterios de aceptación

Los filtros opcionales no se convierten arbitrariamente en segmentos de ruta.
La paginación tiene comportamiento y límites explícitos.
Los errores permiten al consumidor corregir la petición.

Evidencia para revisión

Tabla de operaciones y parámetros.
Matriz de estados y condiciones.

Reinicio de esta parte: Volver al checkpoint de la parte 1 o reconstruirlo desde una copia limpia de los materiales.

Pista · La ruta identifica; la query modifica la consulta

Utiliza esta regla como punto de partida y registra cualquier excepción.

Parte 3 · Guiado ligero

EX-B1-S02-03 · Esqueleto de contrato OpenAPI

Trasladar el diseño a un contrato que un consumidor pueda leer y convertir en casos de prueba.

Qué debes hacer

Completa paths, parameters y responses del esqueleto proporcionado.
Define schemas reutilizables para observación, colección paginada y error.
Incluye ejemplos mínimos coherentes con la muestra.
Revisa required, tipos, formatos y referencias.

Entrega esperada

Documento OpenAPI legible, autocontenido y estructuralmente válido.
Tres casos de prueba descritos en lenguaje natural a partir del contrato.

Criterios de aceptación

Un consumidor puede formular una petición válida sin información externa.
Las respuestas satisfactoria y de error tienen schemas identificables.
Los ejemplos no contradicen tipos ni campos requeridos.

Evidencia para revisión

Documento OpenAPI legible, autocontenido y estructuralmente válido.
Tres casos de prueba descritos a partir del contrato.

Reinicio de esta parte: Volver al checkpoint de la parte 2 y descargar una plantilla OpenAPI sin completar.

Pista · Contrato antes que decoración

Prioriza operaciones, parámetros, schemas y respuestas; no necesitas completar todos los campos opcionales de OpenAPI.

Teoría que puedes consultar

Caso profesional extenso

CASE-B1 · Práctica extendida

Auditoría previa de integración

Una organización quiere intercambiar expedientes con un proveedor, pero requisitos, tráfico y OpenAPI no describen el mismo comportamiento. Tu trabajo es convertir esa incertidumbre en un contrato revisable antes de que empiece la implementación.

Abrir el encargo completo

Pregunta central

Información que necesitas

Para ordenar tu razonamiento

Pistas opcionales

Contexto adicional

Cómo revisar tu respuesta

Evidencia, revisión y reinicio

Material descargable opcional

Teoría que puedes consultar

Pregunta central

Información que necesitas

Para ordenar tu razonamiento

Selecciona tus respuestas

Pistas opcionales

Contexto adicional

Cómo revisar tu respuesta

Evidencia, revisión y reinicio

Material descargable opcional

Teoría que puedes consultar

Pregunta central

Para ordenar tu razonamiento

Pistas opcionales

Contexto adicional

Decisiones abiertas

Cómo revisar tu respuesta

Evidencia, revisión y reinicio

Material descargable opcional

Teoría que puedes consultar

Pregunta central

Información que necesitas

Para ordenar tu razonamiento

Selecciona tus respuestas

Pistas opcionales

Contexto adicional

Cómo revisar tu respuesta

Evidencia, revisión y reinicio

Material descargable opcional

Teoría que puedes consultar

Pregunta central

Documento OpenAPI

Para ordenar tu razonamiento

Pistas opcionales

Contexto adicional

Cómo revisar tu respuesta

Evidencia, revisión y reinicio

Material descargable opcional

Teoría que puedes consultar

Pregunta central

Información que necesitas

Para ordenar tu razonamiento

Selecciona tus respuestas

Pistas opcionales

Contexto adicional

Cómo revisar tu respuesta

Evidencia, revisión y reinicio

Material descargable opcional

Teoría que puedes consultar

Pregunta central

Información que necesitas

Para ordenar tu razonamiento

Pistas opcionales

Contexto adicional

Cómo revisar tu respuesta

Evidencia, revisión y reinicio

Material descargable opcional

Teoría que puedes consultar

Pregunta central

Información que necesitas

Para ordenar tu razonamiento

Pistas opcionales

Contexto adicional

Cómo revisar tu respuesta

Evidencia, revisión y reinicio

Material descargable opcional

Teoría que puedes consultar

Pregunta central

Diff OpenAPI

Para ordenar tu razonamiento

Pistas opcionales

Contexto adicional