Buscar en proyectos y aprendizaje

Escribe al menos dos caracteres.

↑↓ para recorrer · Esc para cerrar

Elegir espacio

Dos espacios

¿Qué quieres consultar?

Elige el espacio al que quieres entrar.

Biblioteca FastAPIFundamentos HTTP
  1. ·Toda la práctica
  2. 1Fundamentos HTTP
  3. 2Primera API
  4. 3Composición
  5. 4Persistencia
  6. ↺Respuestas guardadas
  7. CCaso profesional
  8. ✓Proyecto integrador

Laboratorio ejecutable · Bloque 1

EX-B1-01

Corregir una actualización rechazada

Una aplicación dejó de actualizar expedientes después de que el endpoint adoptara JSON Merge Patch. El ticket incluye el requisito vigente, el comando `curl` usado para reproducir el fallo y la respuesta completa del servidor.

  • Escribir y ejecutar código
  • Debugging de una API
  • Inicial
  • Apoyo alto
  • Starter ejecutable

Cómo abordarla

Observa el fundamento construyendo una API

Descarga el starter, predice un resultado, ejecuta, modifica la API y vuelve a observar. La explicación breve acompaña al código; no lo sustituye.

Abrir laboratorio de código

1. Descarga y arranca

2. Escribe y prueba

  1. Extrae el starter, instala el entorno y ejecuta la suite para conservar el fallo inicial.
  2. Implementa `PATCH /v1/records/{record_id}`: rechaza cualquier `Content-Type` distinto de `application/merge-patch+json` con 415 y aplica solo `state` o `notify` enviados.
  3. Añade una prueba negativa para el media type incorrecto y otra positiva que demuestre que un campo omitido no cambia.
  4. Arranca Uvicorn y ejecuta los dos comandos `curl`; conserva status, body y `X-Request-ID`.

3. Demuestra el comportamiento

  • Parche de `app.py` y tests propios.
  • Salida de pytest antes/después y dos intercambios HTTP reales: rechazo 415 y actualización aceptada.
  • Nota causal de un párrafo que conecte contrato, implementación y evidencia.

La respuesta principal es tu código y sus pruebas. Usa este espacio solo para anotar la predicción inicial y el resultado observado.

Predicción breve antes de ejecutar

Antes de editar, ¿qué petición esperas que falle y qué cambio observable debe hacer que pase sin aceptar media types incorrectos?

Información que necesitas

Endpoint requirement
PATCH /v1/records/{record_id}
Content-Type: application/merge-patch+json
Body fields: state (draft | in_review | closed), notify (boolean)

Reproduction
curl --include --request PATCH \
  'https://records.internal.example/v1/records/REC-204' \
  --header 'Accept: application/json' \
  --header 'Content-Type: application/json' \
  --data '{"state":"in_review","notify":false}'

HTTP/1.1 415 Unsupported Media Type
Content-Type: application/problem+json
Content-Length: 108
X-Request-ID: req-8f21

{"title":"Unsupported Media Type","status":415,"detail":"Content-Type must be application/merge-patch+json"}

Comprueba estas tres cosas

  1. Localiza el media type exigido por el contrato y el que envía el cliente.
  2. Relaciona esa divergencia con el status `415` y con el campo `detail` de la respuesta.
  3. Corrige solo el header necesario y explica por qué el intercambio no demuestra todavía que el payload será aceptado.

Anota predicción, comando ejecutado y diferencia observada; el código vive en tu workspace.

Sin respuesta guardada.

Pistas opcionales

Pista 1 · Compara contrato y request
  • Busca el mismo concepto —`Content-Type`— en el requisito y en el comando.
  • Método, ruta y campos del body ya coinciden; no los cambies sin evidencia.
Pista 2 · Usa la respuesta
  • `415` significa que el servidor rechaza el media type de la representación enviada.
  • El campo `detail` nombra además el valor que exige el endpoint.
Pista 3 · Limita la conclusión
  • Corregir este header elimina una causa demostrada, pero no ejecuta por sí solo las reglas de negocio.
  • Conserva `req-8f21` para investigar el intento original; una nueva ejecución normalmente recibirá otro identificador.
Profundización opcional

Reproducir el `415`, implementar la frontera de media type de un endpoint PATCH y demostrar éxito y rechazo mediante tests y tráfico real.

Contexto adicional

  • El endpoint exige `application/merge-patch+json` porque el body describe una actualización parcial, no la representación completa del recurso.
  • El comando de reproducción usa el método y la ruta correctos, pero declara otro `Content-Type`.
  • La respuesta incluye status, media type, un detalle legible y `X-Request-ID`; no necesitas reconstruir información ausente.

Cómo revisar tu respuesta

  • La causa se identifica como la divergencia entre `application/json` y `application/merge-patch+json`.
  • El comando corregido no cambia `PATCH`, la URL ni el JSON.
  • El endpoint queda ejecutable y las pruebas positivas y negativas pasan desde un ZIP limpio.
  • Omitir `notify` conserva su valor y enviar un tipo inválido no muta el registro.
  • La explicación usa el `415` y el campo `detail` como evidencia, no como suposición.
  • No se afirma que la segunda petición vaya a responder `200`; aún pueden fallar autenticación, versión, validación o reglas de negocio.
  • `X-Request-ID: req-8f21` se reconoce como identificador útil para buscar la ejecución rechazada en logs.

Evidencia, revisión y reinicio

  • Tests antes y después de la reparación.
  • Endpoint PATCH ejecutable, comando `curl` y respuesta HTTP corregida.

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

Reinicio: Eliminar el workspace temporal y volver a extraer el ZIP; no existe estado externo.

Teoría que puedes consultar