**FastAPI** **extraerá** los datos para **cada campo** de los **parámetros query** en el request y te proporcionará el modelo de Pydantic que definiste.

## Revisa la Documentación { #check-the-docs }

Puedes ver los parámetros query en la UI de documentación en `/docs`:

<div class="screenshot">
<img src="/img/tutorial/query-param-models/image01.png">
</div>

### `Body` con `examples` { #body-with-examples }

Aquí pasamos `examples` que contiene un ejemplo de los datos esperados en `Body()`:

{* ../../docs_src/schema_extra_example/tutorial003_an_py310.py hl[22:29] *}

### Ejemplo en la interfaz de documentación { #example-in-the-docs-ui }

Con cualquiera de los métodos anteriores se vería así en los `/docs`:

<img src="/img/tutorial/body-fields/image01.png">

* No te preocupes demasiado por cosas como los estilos de los mensajes de commit, yo haré squash y merge personalizando el commit manualmente.

* Tampoco te preocupes por las reglas de estilo, hay herramientas automatizadas verificando eso.

Y si hay alguna otra necesidad de estilo o consistencia, pediré directamente eso, o agregaré commits encima con los cambios necesarios.

### Revisa el código { #check-the-code }

app = SomeASGIApp()

new_app = UnicornMiddleware(app, some_config="rainbow")
```

Pero FastAPI (en realidad Starlette) proporciona una forma más simple de hacerlo que asegura que los middlewares internos manejen errores del servidor y los controladores de excepciones personalizadas funcionen correctamente.

Para eso, usas `app.add_middleware()` (como en el ejemplo para CORS).

```Python
from fastapi import FastAPI

* validación de datos
* serialización de datos
* documentación de datos, etc.

Esto funciona de la misma manera que con los modelos de Pydantic. Y en realidad se logra de la misma manera internamente, utilizando Pydantic.

/// info | Información

Ten en cuenta que los dataclasses no pueden hacer todo lo que los modelos de Pydantic pueden hacer.

Así que, podrías necesitar seguir usando modelos de Pydantic.

Aquí viste cómo usar múltiples **workers** para **paralelizar** la ejecución de la aplicación, aprovechar los **múltiples núcleos** del CPU, y poder servir **más requests**.

De la lista de conceptos de despliegue de antes, usar workers ayudaría principalmente con la parte de **replicación**, y un poquito con los **reinicios**, pero aún necesitas encargarte de los otros:

* **Seguridad - HTTPS**
* **Ejecución al inicio**
* ***Reinicios***

# Codificador compatible con JSON { #json-compatible-encoder }

Hay algunos casos en los que podrías necesitar convertir un tipo de dato (como un modelo de Pydantic) a algo compatible con JSON (como un `dict`, `list`, etc).

Por ejemplo, si necesitas almacenarlo en una base de datos.

Para eso, **FastAPI** proporciona una función `jsonable_encoder()`.

## Usando el `jsonable_encoder` { #using-the-jsonable-encoder }

    * En requests y responses, manejado igual que un `float`.
* Puedes revisar todos los tipos de datos válidos de Pydantic aquí: <a href="https://docs.pydantic.dev/latest/usage/types/types/" class="external-link" target="_blank">Tipos de datos de Pydantic</a>.

## Ejemplo { #example }

Aquí tienes un ejemplo de una *path operation* con parámetros usando algunos de los tipos anteriores.

Los ejemplos aquí usan `.dict()` para compatibilidad con Pydantic v1, pero deberías usar `.model_dump()` si puedes usar Pydantic v2.

///

Eso generaría un `dict` solo con los datos que se establecieron al crear el modelo `item`, excluyendo los valores por defecto.

Además, los **clientes generados automáticamente** tendrán interfaces más simples, para que los desarrolladores que se comuniquen con tu API puedan tener una experiencia mucho mejor trabajando con tu API. 😎

///