/// tip | Dica

Para entender variáveis de ambiente, você pode ler [Variáveis de Ambiente](../environment-variables.md){.internal-link target=_blank}.

///

## Tipagem e validação { #types-and-validation }

Essas variáveis de ambiente só conseguem lidar com strings de texto, pois são externas ao Python e precisam ser compatíveis com outros programas e com o resto do sistema (e até com diferentes sistemas operacionais, como Linux, Windows, macOS).

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.

OpenAPI tem uma forma para definir múltiplos “esquemas” de segurança.

Por usá-los, você pode ter vantagens de todas essas ferramentas baseadas nos padrões, incluindo os sistemas de documentação interativa.

OpenAPI define os seguintes esquemas de segurança:

* `apiKey`: uma chave específica de aplicação que pode vir de:
    * Um parâmetro query.

{* ../../fastapi/openapi/docs.py ln[9:24] hl[18:24] *}

Você pode substituir qualquer um deles definindo um valor diferente no argumento `swagger_ui_parameters`.

Por exemplo, para desabilitar `deepLinking` você pode passar essas configurações para `swagger_ui_parameters`:

{* ../../docs_src/configure_swagger_ui/tutorial003_py39.py hl[3] *}

## Outros parâmetros da UI do Swagger { #other-swagger-ui-parameters }

Mas você ainda pode documentar como descrito em [Retornos Adicionais no OpenAPI](additional-responses.md){.internal-link target=_blank}.

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

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

Essas informações estão disponíveis no **schema OpenAPI** do app e são mostradas na documentação da API.

E essas mesmas informações dos modelos que estão incluídas no OpenAPI são o que pode ser usado para **gerar o código do cliente**.

### Hey API { #hey-api }

Um `Request` também tem um `request.receive`, que é uma função para "receber" o corpo da requisição.

O dicionário `scope` e a função `receive` são ambos parte da especificação ASGI.

E essas duas coisas, `scope` e `receive`, são o que é necessário para criar uma nova instância de `Request`.

Então, mesmo com o código acima que não usa Pydantic explicitamente, o FastAPI está usando Pydantic para converter essas dataclasses padrão para a versão do Pydantic.

E claro, ele suporta o mesmo:

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

# Subdependências { #sub-dependencies }

Você pode criar dependências que possuem **subdependências**.

Elas podem ter o nível de **profundidade** que você achar necessário.

O **FastAPI** se encarrega de resolver essas dependências.

## Primeira dependência "dependable" { #first-dependency-dependable }

Você pode criar uma primeira dependência ("dependable") dessa forma:

{* ../../docs_src/dependencies/tutorial005_an_py310.py hl[8:9] *}

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.