///

Puedes declarar responses adicionales, con códigos de estado adicionales, media types, descripciones, etc.

Esos responses adicionales se incluirán en el esquema de OpenAPI, por lo que también aparecerán en la documentación de la API.

Pero para esos responses adicionales tienes que asegurarte de devolver un `Response` como `JSONResponse` directamente, con tu código de estado y contenido.

///

## Qué es "Form Data" { #what-is-form-data }

La manera en que los formularios de HTML (`<form></form>`) envían los datos al servidor normalmente utiliza una codificación "especial" para esos datos, es diferente de JSON.

**FastAPI** se asegurará de leer esos datos del lugar correcto en lugar de JSON.

/// note | Detalles Técnicos

En las versiones de FastAPI antes de 0.99.0 (0.99.0 y superiores usan el nuevo OpenAPI 3.1.0) cuando usabas `example` o `examples` con cualquiera de las otras utilidades (`Query()`, `Body()`, etc.) esos ejemplos no se añadían al JSON Schema que describe esos datos (ni siquiera a la propia versión de JSON Schema de OpenAPI), se añadían directamente a la declaración de la *path operation* en OpenAPI (fuera de las partes de OpenAPI que usan JSON Schema).

///

```Python
commons: CommonQueryParams = Depends(CommonQueryParams)
```

////

**FastAPI** proporciona un atajo para estos casos, en donde la dependencia es *específicamente* una clase que **FastAPI** "llamará" para crear una instance de la clase misma.

Para esos casos específicos, puedes hacer lo siguiente:

En lugar de escribir:

//// tab | Python 3.10+

```Python

Hasta ahora, has estado declarando las partes del request que necesitas con sus tipos.

Tomando datos de:

* El path como parámetros.
* Headers.
* Cookies.
* etc.

Y al hacerlo, **FastAPI** está validando esos datos, convirtiéndolos y generando documentación para tu API automáticamente.

Pero hay situaciones donde podrías necesitar acceder al objeto `Request` directamente.

Pero si los datos no existieran, quieres crearlos y devolver un código de estado HTTP de "CREATED" `201`.

Pero todavía quieres poder filtrar y convertir los datos que devuelves con un `response_model`.

Para esos casos, puedes usar un parámetro `Response`.

## Usa un parámetro `Response` { #use-a-response-parameter }

Puedes declarar un parámetro de tipo `Response` en tu *path operation function* (como puedes hacer para cookies y headers).

{* ../../docs_src/body_nested_models/tutorial003_py310.py hl[12] *}

Con esto, incluso si recibes un request con datos duplicados, se convertirá en un conjunto de elementos únicos.

Y siempre que emitas esos datos, incluso si la fuente tenía duplicados, se emitirá como un conjunto de elementos únicos.

Y también se anotará/documentará en consecuencia.

## Modelos Anidados { #nested-models }

* 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).

Esto es similar a los códigos de estado HTTP 200 (de 200 a 299). Esos códigos de estado "200" significan que de alguna manera hubo un "éxito" en el request.

///

## Headers duplicados { #duplicate-headers }

Es posible recibir headers duplicados. Eso significa, el mismo header con múltiples valores.

Puedes definir esos casos usando una lista en la declaración del tipo.

Recibirás todos los valores del header duplicado como una `list` de Python.

///

## Aprende Más { #learn-more }

Puedes aprender más sobre **GraphQL** en la [documentación oficial de GraphQL](https://graphql.org/).