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

Pero en algún punto, no hubo otra opción que crear algo que proporcionara todas estas funcionalidades, tomando las mejores ideas de herramientas previas y combinándolas de la mejor manera posible, usando funcionalidades del lenguaje que ni siquiera estaban disponibles antes (anotaciones...

{* ../../docs_src/sub_applications/tutorial001_py310.py hl[3, 6:8] *}

### Sub-aplicación { #sub-application }

Luego, crea tu sub-aplicación, y sus *path operations*.

Esta sub-aplicación es solo otra aplicación estándar de FastAPI, pero es la que se "montará":

{* ../../docs_src/sub_applications/tutorial001_py310.py hl[11, 14:16] *}

### Montar la sub-aplicación { #mount-the-sub-application }

Esto es muy útil cuando necesitas:

* Tener lógica compartida (la misma lógica de código una y otra vez).
* Compartir conexiones a bases de datos.
* Imponer seguridad, autenticación, requisitos de roles, etc.
* Y muchas otras cosas...

Todo esto, mientras minimizas la repetición de código.

Esto es porque se espera que **tus usuarios** definan el actual **URL path** donde quieren recibir la request del webhook de alguna otra manera (por ejemplo, un panel web).

### Revisa la documentación { #check-the-docs }

Ahora puedes iniciar tu app e ir a [http://127.0.0.1:8000/docs](http://127.0.0.1:8000/docs).

Desde antes de que **JSON Schema** soportara `examples`, OpenAPI tenía soporte para un campo diferente también llamado `examples`.

Estos `examples` específicos de **OpenAPI** van en otra sección en la especificación de OpenAPI. Van en los **detalles para cada *path operation***, no dentro de cada JSON Schema.

* El frontend almacena temporalmente ese token en algún lugar.
* El usuario hace clic en el frontend para ir a otra sección de la aplicación web frontend.
* El frontend necesita obtener más datos de la API.
    * Pero necesita autenticación para ese endpoint específico.

Si un cliente intenta enviar algunas **cookies extra**, recibirán un response de **error**.

Pobres banners de cookies con todo su esfuerzo para obtener tu consentimiento para que la <dfn title="Esta es otra broma. No me prestes atención. Toma un café para tu cookie. ☕">API lo rechace</dfn>. 🍪

    * Si no usabas FastAPI y utilizabas Starlette directamente (u otra herramienta, como Sanic, Flask, Responder, etc.) tendrías que implementar toda la validación y serialización de datos por ti mismo. Entonces, tu aplicación final aún tendría la misma carga que si hubiera sido construida usando FastAPI. Y en muchos...

En muchos casos tu app de FastAPI será más grande, y probablemente usarás tags para separar diferentes grupos de *path operations*.

Por ejemplo, podrías tener una sección para **items** y otra sección para **users**, y podrían estar separadas por tags:

{* ../../docs_src/generate_clients/tutorial002_py310.py hl[21,26,34] *}

### Genera un Cliente TypeScript con tags { #generate-a-typescript-client-with-tags }

En este ejemplo, los mensajes se escribirán en el archivo `log.txt` *después* de que se envíe el response.

Si hay un query en el request, se escribirá en el log en una tarea en segundo plano.

Y luego otra tarea en segundo plano generada en la *path operation function* escribirá un mensaje usando el parámetro de path `email`.

## Detalles Técnicos { #technical-details }