Pero también puedes declarar múltiples parámetros del cuerpo, por ejemplo `item` y `user`:

{* ../../docs_src/body_multiple_params/tutorial002_py310.py hl[20] *}

En este caso, **FastAPI** notará que hay más de un parámetro del cuerpo en la función (hay dos parámetros que son modelos de Pydantic).

Entonces, usará los nombres de los parámetros como claves (nombres de campo) en el cuerpo, y esperará un cuerpo como:

```JSON
{
    "item": {

También significa que si obtienes datos del objeto `Request` directamente (por ejemplo, leyendo el cuerpo) no serán validados, convertidos o documentados (con OpenAPI, para la interfaz automática de usuario de la API) por FastAPI.

Aunque cualquier otro parámetro declarado normalmente (por ejemplo, el cuerpo con un modelo de Pydantic) seguiría siendo validado, convertido, anotado, etc.

///

Primero, creamos una clase `GzipRequest`, que sobrescribirá el método `Request.body()` para descomprimir el cuerpo si hay un header apropiado.

Si no hay `gzip` en el header, no intentará descomprimir el cuerpo.

De esa manera, la misma clase de ruta puede manejar requests comprimidos con gzip o no comprimidos.

/// info | Información

Observa cómo `Offer` tiene una lista de `Item`s, que a su vez tienen una lista opcional de `Image`s

///

## Cuerpos de listas puras { #bodies-of-pure-lists }

Si el valor superior del cuerpo JSON que esperas es un `array` JSON (una `list` en Python), puedes declarar el tipo en el parámetro de la función, al igual que en los modelos Pydantic:

```Python
images: list[Image]

///

/// tip | Consejo

Para declarar cuerpos de File, necesitas usar `File`, porque de otra manera los parámetros serían interpretados como parámetros query o parámetros de cuerpo (JSON).

///

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

En este ejemplo, no declaramos ningún modelo Pydantic. De hecho, el cuerpo del request ni siquiera se <abbr title="convertido de algún formato plano, como bytes, a objetos de Python">parse</abbr> como JSON, se lee directamente como `bytes`, y la función `magic_data_reader()` sería la encargada de parsearlo de alguna manera.

Sin embargo, podemos declarar el esquema esperado para el cuerpo del request.

* JSON Schema: JSON Schema (do not translate to "Esquema JSON")
* embed: embeber (do not translate to "incrustar")
* request body: request body (do not translate to "cuerpo de la petición")
* response body: response body (do not translate to "cuerpo de la respuesta")
* cross domain: cross domain (do not translate to "dominio cruzado")
* cross origin: cross origin (do not translate to "origen cruzado")

En este caso, podrías querer documentar cómo esa API externa *debería* verse. Qué *path operation* debería tener, qué cuerpo debería esperar, qué response debería devolver, etc.

## Una aplicación con callbacks { #an-app-with-callbacks }

Veamos todo esto con un ejemplo.

Imagina que desarrollas una aplicación que permite crear facturas.

Luego simplemente haces lo mismo en tus pruebas.

Por ejemplo:

* Para pasar un parámetro de *path* o *query*, añádelo a la URL misma.
* Para pasar un cuerpo JSON, pasa un objeto de Python (por ejemplo, un `dict`) al parámetro `json`.
* Si necesitas enviar *Form Data* en lugar de JSON, usa el parámetro `data` en su lugar.
* Para pasar *headers*, usa un `dict` en el parámetro `headers`.

# Cuerpo - Actualizaciones { #body-updates }

## Actualización reemplazando con `PUT` { #update-replacing-with-put }

Para actualizar un ítem puedes utilizar la operación de <a href="https://developer.mozilla.org/en-US/docs/Web/HTTP/Methods/PUT" class="external-link" target="_blank">HTTP `PUT`</a>.