</blockquote>

## Investigação { #investigation }

Você também define de alguma maneira em quais **momentos** a sua aplicação mandará essas requisições ou eventos.

E os **seus usuários** definem de alguma forma (em algum painel por exemplo) a **URL** que a sua aplicação deve enviar essas requisições.

Toda a **lógica** sobre como cadastrar as URLs para os webhooks e o código para enviar de fato as requisições cabe a você definir. Você escreve da maneira que você desejar no **seu próprio código**.

Até agora, você viu apenas como escrever testes síncronos, sem utilizar funções `async`.

Ser capaz de utilizar funções assíncronas em seus testes pode ser útil, por exemplo, quando você está realizando uma consulta em seu banco de dados de maneira assíncrona. Imagine que você deseja testar realizando requisições para a sua aplicação FastAPI e depois verificar que a sua aplicação inseriu corretamente as informações no banco de dados, ao utilizar uma biblioteca assíncrona para banco de dados....

Repare que mesmo que o `item` esteja declarado da mesma maneira que antes, agora é esperado que ele esteja dentro do corpo com uma chave `item`.

///

O **FastAPI** fará a conversão automática a partir da requisição, assim esse parâmetro `item` receberá seu respectivo conteúdo e o mesmo ocorrerá com `user`.

Ele executará a validação dos dados compostos e irá documentá-los de maneira compatível com o esquema OpenAPI e documentação automática.

# Parâmetros de Cookie { #cookie-parameters }

Você pode definir parâmetros de Cookie da mesma maneira que define parâmetros com `Query` e `Path`.

## Importe `Cookie` { #import-cookie }

Primeiro importe `Cookie`:

{* ../../docs_src/cookie_params/tutorial001_an_py310.py hl[3] *}

## Declare parâmetros de `Cookie` { #declare-cookie-parameters }

Então declare os parâmetros de cookie usando a mesma estrutura que em `Path` e `Query`.

Então você pode definir os cabeçalhos nesse objeto de resposta *temporário*.

{* ../../docs_src/response_headers/tutorial002_py310.py hl[1, 7:8] *}

Em seguida você pode retornar qualquer objeto que precisar, da maneira que faria normalmente (um `dict`, um modelo de banco de dados, etc.).

Se você declarou um `response_model`, ele ainda será utilizado para filtrar e converter o objeto que você retornou.

## Sobre segurança, APIs e documentação { #about-security-apis-and-docs }

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 rota* ainda estarão disponíveis onde estão.

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

<div class="screenshot">
<img src="/img/tutorial/cookie-param-models/image01.png">
</div>

/// info | Informação

Tenha em mente que, como os **navegadores lidam com cookies** de maneira especial e por baixo dos panos, eles **não** permitem facilmente que o **JavaScript** lidem com eles.

Se você for na **IU da documentação da API** em `/docs` você poderá ver a **documentação** para cookies das suas *operações de rotas*.

# Parâmetros de Cabeçalho { #header-parameters }

Você pode definir parâmetros de Cabeçalho da mesma maneira que define paramêtros com `Query`, `Path` e `Cookie`.

## Importe `Header` { #import-header }

Primeiro importe `Header`:

{* ../../docs_src/header_params/tutorial001_an_py310.py hl[3] *}

## Declare parâmetros de `Header` { #declare-header-parameters }

E claro, ele suporta o mesmo:

* validação de dados
* serialização de dados
* documentação de dados, etc.

Isso funciona da mesma forma que com os modelos Pydantic. E na verdade é alcançado da mesma maneira por baixo dos panos, usando Pydantic.

/// info | Informação

Lembre-se de que dataclasses não podem fazer tudo o que os modelos Pydantic podem fazer.

Então, você ainda pode precisar usar modelos Pydantic.