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

Isso significa que no lugar do processo normal de seus usuários enviarem requisições para a sua API, é a **sua API** (ou sua aplicação) que poderia **enviar requisições para o sistema deles** (para a API deles, a aplicação deles).

Isso normalmente é chamado de **webhook**.

Portanto, eles serão incluídos na resposta JSON.

/// tip | Dica

Observe que os valores padrão podem ser qualquer coisa, não apenas `None`.

Eles podem ser uma lista (`[]`), um `float` de `10.5`, etc.

///

Caso um cliente tente enviar alguns dados **extras** nos **parâmetros de consulta**, eles receberão um retorno de **erro**.

Por exemplo, se o cliente tentar enviar um parâmetro de consulta `tool` com o valor `plumbus`, como:

```http
https://example.com/items/?limit=10&tool=plumbus
```

Eles receberão um retorno de **erro** informando-os que o parâmetro de consulta `tool` não é permitido:

```json
{

Não deveríamos deixar isso acontecer, eles poderiam sobrescrever um `id` que já atribuimos na base de dados. Decidir o `id` deve ser feito pelo **backend** ou pelo **banco de dados**, **não pelo cliente**.

Além disso, criamos um `secret_name` para o hero, mas até agora estamos retornando ele em todos os lugares, isso não é muito **secreto**... 😅

O mais seguro é o fluxo de código, mas ele é mais complexo para implementar, pois ele necessita mais passos. Como ele é mais complexo, muitos provedores terminam sugerindo o fluxo implícito.

/// note | Nota

É comum que cada provedor de autenticação nomeie os seus fluxos de forma diferente, para torná-lo parte de sua marca.

Mas no final, eles estão implementando o mesmo padrão OAuth2.

///

Por causa disso, o JSON Schema para um modelo pode ser diferente dependendo se ele é usado para **entrada ou saída**:

* para **entrada**, o `description` **não será obrigatório**
* para **saída**, ele será **obrigatório** (e possivelmente `None`, ou em termos de JSON, `null`)

### Modelo para Saída na Documentação { #model-for-output-in-docs }

* Para HTTPS, o servidor precisa ter "certificados" gerados por um terceiro.
    * Esses certificados são na verdade adquiridos de um terceiro, eles não são simplesmente "gerados".
* Certificados têm um tempo de vida.
    * Eles expiram.
    * E então eles precisam ser renovados, adquirindo-os novamente de um terceiro.
* A criptografia da conexão acontece no nível TCP.
    * Essa é uma camada abaixo do HTTP.

Mas você não precisa memorizar o que cada um desses códigos significa.

Você pode usar as variáveis de conveniência de `fastapi.status`.

{* ../../docs_src/response_status_code/tutorial002_py310.py hl[1,6] *}

Eles são apenas uma conveniência, eles possuem o mesmo número, mas dessa forma você pode usar o preenchimento automático do editor para encontrá-los:

<img src="/img/tutorial/response-status-code/image02.png">

/// note | Detalhes Técnicos

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

Se um cliente tentar enviar alguns **cabeçalhos extra**, eles irão receber uma resposta de **erro**.

Por exemplo, se o cliente tentar enviar um cabeçalho `tool` com o valor `plumbus`, ele irá receber uma resposta de **erro** informando que o parâmetro do cabeçalho `tool` não é permitido:

```json
{
    "detail": [
        {