```

Mira las similitudes entre `requests.get(...)` y `@app.get(...)`.

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

* Tener un API simple e intuitivo.
* Usar nombres de métodos HTTP (operaciones) directamente, de una manera sencilla e intuitiva.
* Tener valores por defecto sensatos, pero personalizaciones poderosas.

///

Para crear la *path operation* del callback usa el mismo `APIRouter` que creaste arriba.

Debería verse como una *path operation* normal de FastAPI:

* Probablemente debería tener una declaración del body que debería recibir, por ejemplo `body: InvoiceEvent`.
* Y también podría tener una declaración del response que debería devolver, por ejemplo `response_model=InvoiceEventReceived`.

{* ../../docs_src/dependencies/tutorial008_an_py310.py hl[18:19,26:27] *}

De la misma manera, podrías tener algunas dependencias con `yield` y otras dependencias con `return`, y hacer que algunas de esas dependan de algunas de las otras.

Y podrías tener una sola dependencia que requiera varias otras dependencias con `yield`, etc.

Puedes tener cualquier combinación de dependencias que quieras.

# Sub Aplicaciones - Mounts { #sub-applications-mounts }

Si necesitas tener dos aplicaciones de **FastAPI** independientes, cada una con su propio OpenAPI independiente y su propia interfaz de docs, puedes tener una aplicación principal y "montar" una (o más) sub-aplicación(es).

## Montar una aplicación **FastAPI** { #mounting-a-fastapi-application }

Se añaden nuevas funcionalidades con frecuencia, se corrigen bugs regularmente, y el código sigue mejorando continuamente.

Por eso las versiones actuales siguen siendo `0.x.x`, esto refleja que cada versión podría tener potencialmente cambios incompatibles. Esto sigue las convenciones de [Semantic Versioning](https://semver.org/).

Usando estas ideas, JWT puede ser utilizado para escenarios mucho más sofisticados.

En esos casos, varias de esas entidades podrían tener el mismo ID, digamos `foo` (un usuario `foo`, un coche `foo`, y un artículo del blog `foo`).

| `license_info` | `dict` | La información de la licencia para la API expuesta....

Podrías poner esas configuraciones en otro archivo de módulo como viste en [Aplicaciones Más Grandes - Múltiples Archivos](../tutorial/bigger-applications.md).

Por ejemplo, podrías tener un archivo `config.py` con:

{* ../../docs_src/settings/app01_py310/config.py *}

Y luego usarlo en un archivo `main.py`:

{* ../../docs_src/settings/app01_py310/main.py hl[3,11:13] *}

/// tip | Consejo

    * Un caso especial es `204`, "No Content". Este response se usa cuando no hay contenido para devolver al cliente, por lo tanto, el response no debe tener un body.
* **`300 - 399`** son para "Redirección". Los responses con estos códigos de estado pueden o no tener un body, excepto `304`, "Not Modified", que no debe tener uno.
* **`400 - 499`** son para responses de "Error del Cliente". Este es el segundo tipo que probablemente más usarías.

///

## Devolver el token { #return-the-token }

El response del endpoint `token` debe ser un objeto JSON.

Debe tener un `token_type`. En nuestro caso, como estamos usando tokens "Bearer", el tipo de token debe ser "`bearer`".

Y debe tener un `access_token`, con un string que contenga nuestro token de acceso.