Lo mismo sucedería si tuvieras algo como una <dfn title='una unión entre múltiples tipos significa "cualquiera de estos tipos".'>unión</dfn> entre diferentes tipos donde uno o más de ellos no son tipos válidos de Pydantic, por ejemplo esto fallaría 💥:

* y allí, busca el módulo `dependencies` (el archivo en `app/dependencies.py`)...
* y de él, importa la función `get_token_header`.

¡Eso funciona correctamente! 🎉

---

De la misma manera, si hubiéramos usado tres puntos `...`, como en:

```Python
from ...dependencies import get_token_header
```

eso significaría:

Si tienes una app de FastAPI antigua, podrías estar usando Pydantic versión 1.

FastAPI versión 0.100.0 tenía compatibilidad con Pydantic v1 o v2. Usaba la que tuvieras instalada.

FastAPI versión 0.119.0 introdujo compatibilidad parcial con Pydantic v1 desde dentro de Pydantic v2 (como `pydantic.v1`), para facilitar la migración a v2.

/// tip | Consejo

Ahora usamos `response_model=HeroPublic` en lugar de la **anotación de tipo de retorno** `-> HeroPublic` porque el valor que estamos devolviendo en realidad *no* es un `HeroPublic`.

Si hubiéramos declarado `-> HeroPublic`, tu editor y linter se quejarían (con razón) de que estás devolviendo un `Hero` en lugar de un `HeroPublic`.

Ha habido muchas herramientas creadas antes que han ayudado a inspirar su creación.

He estado evitando la creación de un nuevo framework durante varios años. Primero traté de resolver todas las funcionalidades cubiertas por **FastAPI** usando varios frameworks, plug-ins y herramientas diferentes.

# Transmitir JSON Lines { #stream-json-lines }

Podrías tener una secuencia de datos que quieras enviar en un "**stream**", podrías hacerlo con **JSON Lines**.

/// info | Información

Añadido en FastAPI 0.134.0.

///

## ¿Qué es un Stream? { #what-is-a-stream }

Hacer "**Streaming**" de datos significa que tu app empezará a enviar ítems de datos al cliente sin esperar a que toda la secuencia de ítems esté lista.

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 { #documenting-webhooks-with-fastapi-and-openapi }

Y la especificación dice que los campos deben llamarse así. Por lo que `user-name` o `email` no funcionarían.

Pero no te preocupes, puedes mostrarlo como quieras a tus usuarios finales en el frontend.

Y tus modelos de base de datos pueden usar cualquier otro nombre que desees.

Pero puedes tener miles de endpoints (*path operations*) usando el mismo sistema de seguridad.

Y todos ellos (o cualquier porción de ellos que quieras) pueden aprovechar la reutilización de estas dependencias o cualquier otra dependencia que crees.

Y todas estas miles de *path operations* pueden ser tan pequeñas como 3 líneas:

Y tiene la misma forma y estructura que todas tus *path operation functions*.

Puedes pensar en ella como una *path operation function* sin el "decorador" (sin el `@app.get("/some-path")`).

Y puede devolver lo que quieras.

En este caso, esta dependencia espera:

* Un parámetro de query opcional `q` que es un `str`.
* Un parámetro de query opcional `skip` que es un `int`, y por defecto es `0`.