### Renovación de Certificados { #certificate-renewal }

En algún momento en el futuro, cada certificado **expiraría** (alrededor de 3 meses después de haberlo adquirido).

Y entonces, habría otro programa (en algunos casos es otro programa, en algunos casos podría ser el mismo TLS Termination Proxy) que hablaría con Let's Encrypt y renovaría el/los certificado(s).

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

**proyectos**. Eso es muy difícil de manejar. Y probablemente terminarías ejecutando algunos proyectos con algunas **versiones incompatibles** de los paquetes, y sin saber por qué algo no está funcionando.

Además, dependiendo de tu sistema operativo (por ejemplo, Linux, Windows, macOS), podría haber venido con Python ya instalado. Y en ese caso probablemente tenía algunos paquetes preinstalados con algunas versiones específicas **necesitadas por tu sistema**. Si instalas paquetes en el entorno...

Son manejados automáticamente por **FastAPI** y convertidos a JSON.

///

## Agrega headers personalizados { #add-custom-headers }

Existen algunas situaciones en las que es útil poder agregar headers personalizados al error HTTP. Por ejemplo, para algunos tipos de seguridad.

Probablemente no necesitarás usarlos directamente en tu código.

### `HTMLResponse` { #htmlresponse }

Toma algún texto o bytes y devuelve un response HTML, como leíste arriba.

### `PlainTextResponse` { #plaintextresponse }

Toma algún texto o bytes y devuelve un response de texto plano.

{* ../../docs_src/custom_response/tutorial005_py39.py hl[2,7,9] *}

### `JSONResponse` { #jsonresponse }

Toma algunos datos y devuelve un response codificado como `application/json`.

## 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.

Ahora vamos a lo divertido. 🎉

## Agregar `Query` a `Annotated` en el parámetro `q` { #add-query-to-annotated-in-the-q-parameter }

Ahora que tenemos este `Annotated` donde podemos poner más información (en este caso algunas validaciones adicionales), agrega `Query` dentro de `Annotated`, y establece el parámetro `max_length` a `50`:

{* ../../docs_src/query_params_str_validations/tutorial002_an_py310.py hl[9] *}

{* ../../docs_src/dependencies/tutorial006_an_py39.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**.

///

Las dependencias con `yield` han evolucionado con el tiempo para cubrir diferentes casos de uso y arreglar algunos problemas; aquí tienes un resumen de lo que ha cambiado.

### Dependencias con `yield` y `scope` { #dependencies-with-yield-and-scope }