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

9ejercicios independientes

Directossin archivos ni entrega obligatoria

2 + 1series y caso para profundizar

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.

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.

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.

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.

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 fragmento OpenAPI, ¿qué petición válida harías para buscar obras y qué respuestas puede recibir un consumidor?

Información que necesitas

GET /obras
Query opcional:
  q: string, mínimo 2 caracteres
  tipo: pintura | escultura | fotografia
  limite: integer, 1..50, default 20

Respuestas:
  200 -> WorkCollection
  400 -> Problem

GET /obras/{work_id}
  work_id: string requerido, patrón wrk-[0-9]+
  200 -> Work
  404 -> Problem

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 contrato OpenAPI reducido.

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.

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ó.

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.

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.

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?

Información que necesitas

Cambios propuestos:
1. /records/{record_id} pasa a /record/{id}
2. El identificador pasa de integer a string
3. owner_id se añade como campo requerido
4. archived_at se añade como string o null opcional
5. La respuesta 404 desaparece y 200 puede contener null
6. Se documenta una nueva respuesta 429

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.

Material descargable opcional

Diff OpenAPICambios propuestos entre v1 y v1.1 con contexto limitado.
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.
Contrato reducidoFragmento OpenAPI que describe la creación de expedientes.
Cuaderno de la serieCheckpoint vacío para conservar evidencias, hipótesis y decisiones entre partes.

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.

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.

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.

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.

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.

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.

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

Fragmento OpenAPI legible y autocontenido.
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.

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

Práctica extendida · Caso profesional B1

Auditoría previa de integración

Revisa una propuesta de intercambio de expedientes con requisitos contradictorios, mensajes HTTP, JSON y un fragmento OpenAPI. La entrega combina inventario de recursos, contrato corregido, matriz de estados, riesgos y preguntas al cliente.

Abrir el encargo completo

Pregunta central

Información que necesitas

Para ordenar tu razonamiento

Pistas opcionales

Contexto adicional

Cómo revisar tu respuesta

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

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

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

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

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

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

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

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

Material descargable opcional

Teoría que puedes consultar

Base común

Paquete de trabajo

EX-B1-S01-01 · Reconstruir el intercambio

Qué debes hacer

Entrega esperada