## Lista de parámetros de Query / múltiples valores { #query-parameter-list-multiple-values }

Cuando defines un parámetro de query explícitamente con `Query` también puedes declararlo para recibir una lista de valores, o dicho de otra manera, para recibir múltiples valores.

Por ejemplo, para declarar un parámetro de query `q` que puede aparecer varias veces en la URL, puedes escribir:

{* ../../docs_src/security/tutorial004_an_py310.py hl[4,7,13:15,29:31,79:87] *}

## Actualizar las dependencias { #update-the-dependencies }

Actualiza `get_current_user` para recibir el mismo token que antes, pero esta vez, usando tokens JWT.

Decodifica el token recibido, verifícalo y devuelve el usuario actual.

Si el token es inválido, devuelve un error HTTP de inmediato.

{* ../../docs_src/security/tutorial004_an_py310.py hl[90:107] *}

# Declarar Ejemplos de Request { #declare-request-example-data }

Puedes declarar ejemplos de los datos que tu aplicación puede recibir.

Aquí tienes varias formas de hacerlo.

## Datos extra de JSON Schema en modelos de Pydantic { #extra-json-schema-data-in-pydantic-models }

Puedes declarar `examples` para un modelo de Pydantic que se añadirá al JSON Schema generado.

//// tab | Pydantic v2

En este ejemplo estamos usando el flujo de OAuth2 "password".

Esto es apropiado cuando estamos iniciando sesión en nuestra propia aplicación, probablemente con nuestro propio frontend.

Porque podemos confiar en ella para recibir el `username` y `password`, ya que la controlamos.

### Documentación de la API { #api-docs }

Si vas a `/docs`, verás que tiene los **esquemas** para los datos a enviar en requests y recibir en responses:

<img src="/img/tutorial/generate-clients/image01.png">

Puedes ver esos esquemas porque fueron declarados con los modelos en la app.

Si revisas la aplicación anterior, en la interfaz verás que, hasta ahora, permite al cliente decidir el `id` del `Hero` a crear. 😱

No deberíamos permitir que eso suceda, podrían sobrescribir un `id` que ya tenemos asignado en la base de datos. Decidir el `id` debería ser tarea del **backend** o la **base de datos**, **no del cliente**.

Esos worker processes serían los que ejecutan tu aplicación, realizarían los cálculos principales para recibir un **request** y devolver un **response**, y cargarían cualquier cosa que pongas en variables en RAM.

<img src="/img/deployment/concepts/process-ram.drawio.svg">

![ReDoc](https://fastapi.tiangolo.com/img/index/index-02-redoc-simple.png)

## Actualización del Ejemplo { #example-upgrade }

Ahora modifica el archivo `main.py` para recibir un body desde un request `PUT`.

Declara el body usando tipos estándar de Python, gracias a Pydantic.

```Python hl_lines="4  9-12  25-27"
from typing import Union

from fastapi import FastAPI

La clave aquí es el `await`. Dice a Python que tiene que esperar ⏸ a que `get_burgers(2)` termine de hacer su cosa 🕙 antes de almacenar los resultados en `burgers`. Con eso, Python sabrá que puede ir y hacer algo más 🔀 ⏯ mientras tanto (como recibir otro request).

Para que `await` funcione, tiene que estar dentro de una función que soporte esta asincronía. Para hacer eso, solo declara la función con `async def`:

```Python hl_lines="1"

Allí puedes seleccionar "Releases only".

Al hacerlo, recibirás notificaciones (en tu email) cada vez que haya un nuevo lanzamiento (una nueva versión) de **FastAPI** con correcciones de bugs y nuevas funcionalidades.

## Conéctate con el autor { #connect-with-the-author }