Comencemos con un ejemplo y luego veámoslo en detalle.

Creamos una función asíncrona `lifespan()` con `yield` así:

{* ../../docs_src/events/tutorial003.py hl[16,19] *}

Por ejemplo, con un ID de `42`, esto se renderizaría como:

```html
<a href="/items/42">
```

## Plantillas y archivos estáticos

También puedes usar `url_for()` dentro de la plantilla, y usarlo, por ejemplo, con los `StaticFiles` que montaste con el `name="static"`.

```jinja hl_lines="4"
{!../../docs_src/templates/templates/item.html!}

# Middleware

Puedes añadir middleware a las aplicaciones de **FastAPI**.

Un "middleware" es una función que trabaja con cada **request** antes de que sea procesada por cualquier *path operation* específica. Y también con cada **response** antes de devolverla.

* Toma cada **request** que llega a tu aplicación.
* Puede entonces hacer algo a esa **request** o ejecutar cualquier código necesario.

///

### Incluir un `APIRouter` con un `prefix`, `tags`, `responses`, y `dependencies` personalizados

Ahora, imaginemos que tu organización te dio el archivo `app/internal/admin.py`.

Contiene un `APIRouter` con algunas *path operations* de administración que tu organización comparte entre varios proyectos.

```console
// Podrías crear una env var MY_NAME con
$ export MY_NAME="Wade Wilson"

// Luego podrías usarla con otros programas, como
$ echo "Hello $MY_NAME"

Hello Wade Wilson
```

</div>

////

//// tab | Windows PowerShell

<div class="termy">

```console
// Crea una env var MY_NAME
$ $Env:MY_NAME = "Wade Wilson"

// Úsala con otros programas, como
$ echo "Hello $Env:MY_NAME"

* `externalDocs`: un `dict` que describe documentación externa con:
    * `description`: un `str` con una breve descripción para la documentación externa.
    * `url` (**requerido**): un `str` con la URL para la documentación externa.

### Crear metadata para etiquetas

Probemos eso en un ejemplo con etiquetas para `users` y `items`.

Crea metadata para tus etiquetas y pásala al parámetro `openapi_tags`:

Toda la **lógica** sobre cómo registrar los URLs para webhooks y el código para realmente enviar esas requests depende de ti. Lo escribes como quieras en **tu propio código**.

## Documentando webhooks con **FastAPI** y OpenAPI

* El frontend (ejecutándose en el navegador del usuario) envía ese `username` y `password` a una URL específica en nuestra API (declarada con `tokenUrl="token"`).
* La API verifica ese `username` y `password`, y responde con un "token" (no hemos implementado nada de esto aún).
    * Un "token" es solo un string con algún contenido que podemos usar luego para verificar a este usuario.

### Requests de preflight CORS

Estos son cualquier request `OPTIONS` con headers `Origin` y `Access-Control-Request-Method`.

En este caso, el middleware interceptará el request entrante y responderá con los headers CORS adecuados, y un response `200` o `400` con fines informativos.

### Requests simples

Si hay una falla de seguridad en tu código, seguirá existiendo.

Ocultar la documentación solo hace que sea más difícil entender cómo interactuar con tu API y podría dificultar más depurarla en producción. Podría considerarse simplemente una forma de <a href="https://en.wikipedia.org/wiki/Security_through_obscurity" class="external-link" target="_blank">Seguridad mediante oscuridad</a>.