Esta es la idea básica. Pero probablemente querrás encargarte de algunas cosas adicionales, como:

* Seguridad - HTTPS
* Ejecución en el arranque
* Reinicios
* Replicación (el número de procesos ejecutándose)
* Memoria
* Pasos previos antes de comenzar

#### El tiempo de respuesta ayuda a los atacantes { #the-time-to-answer-helps-the-attackers }

En ese punto, al notar que el servidor tardó algunos microsegundos más en enviar el response "Nombre de usuario o contraseña incorrectos", los atacantes sabrán que acertaron en _algo_, algunas de las letras iniciales eran correctas.

## No Separar Esquemas { #do-not-separate-schemas }

Ahora, hay algunos casos donde podrías querer tener el **mismo esquema para entrada y salida**.

Probablemente el caso principal para esto es si ya tienes algún código cliente/SDKs autogenerado y no quieres actualizar todo el código cliente/SDKs autogenerado aún, probablemente querrás hacerlo en algún momento, pero tal vez no ahora.

{* ../../docs_src/dependencies/tutorial006_an_py310.py hl[19] *}

Estas dependencias serán ejecutadas/resueltas de la misma manera que las dependencias normales. Pero su valor (si devuelven alguno) no será pasado a tu *path operation function*.

/// tip | Consejo

Algunos editores revisan los parámetros de función no usados y los muestran como errores.

## Prohibir Headers Extra { #forbid-extra-headers }

En algunos casos de uso especiales (probablemente no muy comunes), podrías querer **restringir** los headers que deseas recibir.

Puedes usar la configuración del modelo de Pydantic para `prohibir` cualquier campo `extra`:

{* ../../docs_src/header_param_models/tutorial002_an_py310.py hl[10] *}

Si un cliente intenta enviar algunos **headers extra**, recibirán un response de **error**.

En algunos casos de uso especiales (probablemente no muy comunes), podrías querer **restringir** los parámetros query que deseas recibir.

Puedes usar la configuración del modelo de Pydantic para `forbid` cualquier campo `extra`:

{* ../../docs_src/query_param_models/tutorial002_an_py310.py hl[10] *}

El proceso normalmente es que **tú defines** en tu código cuál es el mensaje que enviarás, el **body de la request**.

También defines de alguna manera en qué **momentos** tu aplicación enviará esas requests o eventos.

Y **tus usuarios** definen de alguna manera (por ejemplo en un panel web en algún lugar) el **URL** donde tu aplicación debería enviar esas requests.

Hay algunos escenarios donde podrías querer sobrescribir una dependencia durante las pruebas.

No quieres que la dependencia original se ejecute (ni ninguna de las sub-dependencias que pueda tener).

# Configurar Swagger UI { #configure-swagger-ui }

Puedes configurar algunos [parámetros adicionales de Swagger UI](https://swagger.io/docs/open-source-tools/swagger-ui/usage/configuration/).

Para configurarlos, pasa el argumento `swagger_ui_parameters` al crear el objeto de la app `FastAPI()` o a la función `get_swagger_ui_html()`.

`swagger_ui_parameters` recibe un diccionario con las configuraciones pasadas directamente a Swagger UI.

/// tip | Consejo

**GraphQL** resuelve algunos casos de uso muy específicos.

Tiene **ventajas** y **desventajas** en comparación con las **APIs web** comunes.

Asegúrate de evaluar si los **beneficios** para tu caso de uso compensan los **inconvenientes**. 🤓

///

## Paquetes de GraphQL { #graphql-libraries }