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

/// note | Detalhes Técnicos

`Header` é uma classe "irmã" de `Path`, `Query` e `Cookie`. Ela também herda da mesma classe em comum `Param`.

Mas lembre-se que quando você importa `Query`, `Path`, `Header`, e outras de `fastapi`, elas são na verdade funções que retornam classes especiais.

///

/// info | Informação

        function ->> code: return stored result
    end
```

No caso da nossa dependência `get_settings()`, a função nem recebe argumentos, então ela sempre retorna o mesmo valor.

Dessa forma, ela se comporta quase como se fosse apenas uma variável global. Mas como usa uma função de dependência, podemos sobrescrevê-la facilmente para testes.

Note que as *operações de rota* definem os modelos que usam para o corpo da requisição e o corpo da resposta, usando os modelos `Item` e `ResponseMessage`.

### Documentação da API { #api-docs }

Se você for para `/docs`, verá que ela tem os **schemas** para os dados a serem enviados nas requisições e recebidos nas respostas:

<img src="/img/tutorial/generate-clients/image01.png">

Você pode ver esses schemas porque eles foram declarados com os modelos no app.

Importe o `SQLModel` e crie um modelo de banco de dados:

{* ../../docs_src/sql_databases/tutorial001_an_py310.py ln[1:11] hl[7:11] *}

A classe `Hero` é muito semelhante a um modelo Pydantic (na verdade, por baixo dos panos, ela *é um modelo Pydantic*).

Existem algumas diferenças:

/// warning | Atenção

Uvicorn e outros servidores suportam a opção `--reload` que é útil durante o desenvolvimento.

A opção `--reload` consome muito mais recursos, é mais instável, etc.

Ela ajuda muito durante o **desenvolvimento**, mas você **não deve** usá-la em **produção**.

///

## Conceitos de Implantação { #deployment-concepts }

Com isso, você pode rolar, vendo as opções, até encontrar o que "soa familiar":

<img src="/img/python-types/image03.png">

## Mais motivação { #more-motivation }

Verifique esta função, ela já possui type hints:

{* ../../docs_src/python_types/tutorial003_py39.py hl[1] *}

Como o editor conhece os tipos de variáveis, você não obtém apenas o preenchimento automático, mas também as verificações de erro:

Como esse código é executado antes de a aplicação **começar** a receber requisições e logo depois que ela **termina** de lidar com as requisições, ele cobre todo o **lifespan** da aplicação (a palavra "lifespan" será importante em um segundo 😉).

Até agora você apenas viu dependências declaradas como funções.

Mas essa não é a única forma de declarar dependências (mesmo que provavelmente seja a mais comum).

O fator principal para uma dependência é que ela deve ser "chamável"

Um objeto "chamável" em Python é qualquer coisa que o Python possa "chamar" como uma função

Quando você importa `Query`, `Path` e outras de `fastapi`, elas são na verdade funções.

Que, quando chamadas, retornam instâncias de classes de mesmo nome.

Então, você importa `Query`, que é uma função. E quando você a chama, ela retorna uma instância de uma classe também chamada `Query`.

Essas funções existem (em vez de usar diretamente as classes) para que seu editor não marque erros sobre seus tipos.

Então podemos declarar `tags` como um conjunto de strings:

{* ../../docs_src/body_nested_models/tutorial003_py310.py hl[12] *}

Com isso, mesmo que você receba uma requisição contendo dados duplicados, ela será convertida em um conjunto de itens exclusivos.

E sempre que você enviar esses dados como resposta, mesmo se a fonte tiver duplicatas, eles serão gerados como um conjunto de itens exclusivos.