`PATCH` es menos usado y conocido que `PUT`.

Y muchos equipos utilizan solo `PUT`, incluso para actualizaciones parciales.

Eres **libre** de usarlos como desees, **FastAPI** no impone ninguna restricción.

Pero esta guía te muestra, más o menos, cómo se pretende que se usen.

///

### Uso del parámetro `exclude_unset` de Pydantic

Y si declaraste un `response_model`, aún se usará para filtrar y convertir el objeto que devolviste.

**FastAPI** usará ese response *temporal* para extraer los headers (también cookies y el código de estado), y los pondrá en el response final que contiene el valor que devolviste, filtrado por cualquier `response_model`.

También puedes declarar el parámetro `Response` en dependencias y establecer headers (y cookies) en ellas.

### Casos de uso: servicio externo

Un ejemplo podría ser que tienes un proveedor de autenticación externo al que necesitas llamar.

Le envías un token y te devuelve un usuario autenticado.

Este proveedor podría estar cobrándote por cada request, y llamarlo podría tomar más tiempo adicional que si tuvieras un usuario de prueba fijo para los tests.

# Modelos de Parâmetros de Cookie

Se você possui um grupo de **cookies** que estão relacionados, você pode criar um **modelo Pydantic** para declará-los. 🍪

Isso lhe permitiria **reutilizar o modelo** em **diversos lugares** e também declarar validações e metadata para todos os parâmetros de uma vez. 😎

/// note | Nota

Isso é suportado desde a versão `0.115.0` do FastAPI. 🤓

///

/// tip | Dica

Ocultar suas interfaces de usuário de documentação na produção *não deveria* ser a maneira de proteger sua API.

Isso não adiciona nenhuma segurança extra à sua API; as *operações de rotas* ainda estarão disponíveis onde estão.

Se houver uma falha de segurança no seu código, ela ainda existirá.

{* ../../docs_src/dependencies/tutorial011_an_py39.py hl[22] *}

/// tip | Dica

Tudo isso parece não ser natural. E pode não estar muito claro ou aparentar ser útil ainda.

Estes exemplos são intencionalmente simples, porém mostram como tudo funciona.

Nos capítulos sobre segurança, existem funções utilitárias que são implementadas desta maneira.

/// warning | Advertencia

Las claves extra pasadas a `Field` también estarán presentes en el esquema de OpenAPI resultante para tu aplicación.
Como estas claves no necesariamente tienen que ser parte de la especificación de OpenAPI, algunas herramientas de OpenAPI, por ejemplo [el validador de OpenAPI](https://validator.swagger.io/), podrían no funcionar con tu esquema generado.

///

| `description` | `str` | Una breve descripción de la API. Puede usar Markdown. |
| `version` | `string` | La versión de la API. Esta es la versión de tu propia aplicación, no de OpenAPI. Por ejemplo, `2.5.0`. |
| `terms_of_service` | `str` | Una URL a los Términos de Servicio para la API. Si se proporciona, debe ser una URL. |

/// tip | Dica

As próximas seções **não são necessariamente "avançadas"**.

E é possível que para o seu caso de uso, a solução está em uma delas.

///

## Leia o Tutorial primeiro

As próximas seções pressupõem que você já leu o principal [Tutorial - Guia de Usuário: Segurança](../../tutorial/security/index.md){.internal-link target=_blank}.

Há diversas situações em que você precisa notificar um erro a um cliente que está utilizando a sua API.

Esse cliente pode ser um browser com um frontend, o código de outra pessoa, um dispositivo IoT, etc.

Pode ser que você precise comunicar ao cliente que:

* O cliente não tem direitos para realizar aquela operação.
* O cliente não tem acesso aquele recurso.
* O item que o cliente está tentando acessar não existe.
* etc.