## Sobre Pydantic { #about-pydantic }

Pydantic incluye los tests para **FastAPI** con sus propios tests, así que nuevas versiones de Pydantic (por encima de `1.0.0`) siempre son compatibles con FastAPI.

Puedes fijar Pydantic a cualquier versión por encima de `1.0.0` que funcione para ti.

Por ejemplo:

```txt
pydantic>=2.7.0,<3.0.0

## Detalles sobre el objeto `Request` { #details-about-the-request-object }

Como **FastAPI** es en realidad **Starlette** por debajo, con una capa de varias herramientas encima, puedes usar el objeto <a href="https://www.starlette.dev/requests/" class="external-link" target="_blank">`Request`</a> de Starlette directamente cuando lo necesites.

///

## Crear un middleware { #create-a-middleware }

Para crear un middleware usas el decorador `@app.middleware("http")` encima de una función.

La función middleware recibe:

* La `request`.
* Una función `call_next` que recibirá la `request` como parámetro.
    * Esta función pasará la `request` a la correspondiente *path operation*.

Las rutas se declaran en un solo lugar, usando funciones declaradas en otros lugares (en lugar de usar decoradores que pueden colocarse justo encima de la función que maneja el endpoint). Esto se acerca más a cómo lo hace Django que a cómo lo hace Flask (y Starlette). Separa en el código cosas que están relativamente acopladas.

/// check | Inspiró a **FastAPI** a

Y también se usa internamente al montar subaplicaciones.

Tener un proxy con un prefijo de path eliminado, en este caso, significa que podrías declarar un path en `/app` en tu código, pero luego añades una capa encima (el proxy) que situaría tu aplicación **FastAPI** bajo un path como `/api/v1`.

En este caso, el path original `/app` realmente sería servido en `/api/v1/app`.

* el path `/`
* usando una <abbr title="un método HTTP GET"><code>get</code> operation</abbr>

/// info | Información sobre `@decorator`

Esa sintaxis `@algo` en Python se llama un "decorador".

Lo pones encima de una función. Como un bonito sombrero decorativo (supongo que de ahí viene el término).

Un "decorador" toma la función de abajo y hace algo con ella.

```Python
def get_settings():
    return Settings()
```

crearíamos ese objeto para cada request, y estaríamos leyendo el archivo `.env` para cada request. ⚠️

Pero como estamos usando el decorador `@lru_cache` encima, el objeto `Settings` se creará solo una vez, la primera vez que se llame. ✔️

{* ../../docs_src/settings/app03_an_py39/main.py hl[1,11] *}

* 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 }

* Revisa y lee el código, ve si tiene sentido, **ejecútalo localmente** y ve si realmente resuelve el problema.

# Corpo da requisição { #request-body }

Quando você precisa enviar dados de um cliente (como de um navegador) para sua API, você os envia como um **corpo da requisição**.

O corpo da **requisição** é a informação enviada pelo cliente para sua API. O corpo da **resposta** é a informação que sua API envia para o cliente.

Mas para este exemplo, usaremos um documento HTML muito simples com algum JavaScript, tudo dentro de uma string longa.

Esse, é claro, não é o ideal e você não o usaria para produção.

Na produção, você teria uma das opções acima.

Mas é a maneira mais simples de focar no lado do servidor de WebSockets e ter um exemplo funcional:

{* ../../docs_src/websockets/tutorial001_py39.py hl[2,6:38,41:43] *}

## Crie um `websocket` { #create-a-websocket }