En este ejemplo, los mensajes se escribirán en el archivo `log.txt` *después* de que se envíe el response.

Si hay un query en el request, se escribirá en el log en una tarea en segundo plano.

Y luego otra tarea en segundo plano generada en la *path operation function* escribirá un mensaje usando el parámetro de path `email`.

## Detalles Técnicos { #technical-details }

///

Los archivos se subirán como "form data".

Si declaras el tipo de tu parámetro de *path operation function* como `bytes`, **FastAPI** leerá el archivo por ti y recibirás el contenido como `bytes`.

Ten en cuenta que esto significa que todo el contenido se almacenará en memoria. Esto funcionará bien para archivos pequeños.

* `echo "*"`: "imprimirá" el texto `*` en el terminal (la siguiente parte cambia eso un poco)
* `>`: cualquier cosa impresa en el terminal por el comando a la izquierda de `>` no debería imprimirse, sino escribirse en el archivo que va a la derecha de `>`
* `.gitignore`: el nombre del archivo donde debería escribirse el texto

Y `*` para Git significa "todo". Así que, ignorará todo en el directorio `.venv`.

Podrías necesitar decirle al cliente que:

* El cliente no tiene suficientes privilegios para esa operación.
* El cliente no tiene acceso a ese recurso.
* El ítem al que el cliente intentaba acceder no existe.
* etc.

En estos casos, normalmente devolverías un **código de estado HTTP** en el rango de **400** (de 400 a 499).

**FastAPI** tomará el modelo de Pydantic de allí, generará el JSON Schema y lo colocará en el lugar correcto.

El lugar correcto es:

* En la clave `content`, que tiene como valor otro objeto JSON (`dict`) que contiene:
  * Una clave con el media type, por ejemplo, `application/json`, que contiene como valor otro objeto JSON, que contiene:
    * Una clave `schema`, que tiene como valor el JSON Schema del modelo, aquí es el lugar correcto.

# Modelos Extra { #extra-models }

Continuando con el ejemplo anterior, será común tener más de un modelo relacionado.

Esto es especialmente el caso para los modelos de usuario, porque:

* El **modelo de entrada** necesita poder tener una contraseña.
* El **modelo de salida** no debería tener una contraseña.
* El **modelo de base de datos** probablemente necesitaría tener una contraseña hasheada.

/// danger | Peligro

## Pasos de los webhooks { #webhooks-steps }

El proceso normalmente es que **tú defines** en tu código cuál es el mensaje que enviarás, el **body de la request**.

También defines de alguna manera en qué **momentos** tu aplicación enviará esas requests o eventos.

Y **tus usuarios** definen de alguna manera (por ejemplo en un panel web en algún lugar) el **URL** donde tu aplicación debería enviar esas requests.

Son solo una conveniencia, mantienen el mismo número, pero de esa manera puedes usar el autocompletado del editor para encontrarlos:

<img src="/img/tutorial/response-status-code/image02.png">

/// note | Detalles técnicos

También podrías usar `from starlette import status`.

**FastAPI** proporciona el mismo `starlette.status` como `fastapi.status` solo como una conveniencia para ti, el desarrollador. Pero proviene directamente de Starlette.

Este comportamiento se revirtió en la 0.118.0, para hacer que el código de salida después de `yield` se ejecute después de que la response sea enviada.

/// info | Información

```Python
{
    "name": "Barz",
    "price": 3,
    "description": None,
}
```

debido a que no incluye el atributo ya almacenado `"tax": 20.2`, el modelo de entrada tomaría el valor por defecto de `"tax": 10.5`.

Y los datos se guardarían con ese "nuevo" `tax` de `10.5`.

## Actualizaciones parciales con `PATCH` { #partial-updates-with-patch }