Contudo, o cliente ou usuário não terão acesso a ele. Ao contrário, o cliente receberá um "Internal Server Error" com o HTTP status code `500`.

E assim deve ser porque seria um bug no seu código ter o `ValidationError` do Pydantic na sua *response*, ou em qualquer outro lugar do seu código (que não na requisição do cliente).

Por exemplo, vamos dizer que você esteja utilizando a versão `0.45.0` no seu _app_.

Se você usa um arquivo `requirements.txt`, dá para especificar a versão assim:

```txt
fastapi==0.45.0
```

isso significa que você pode usar exatamente a versão `0.45.0`.

Ou você poderia fixar assim:

```txt
fastapi>=0.45.0,<0.46.0
```

**FastAPI** não é uma alternativa para **Requests**. O escopo deles é muito diferente.

Na verdade é comum utilizar Requests *dentro* de uma aplicação FastAPI.

Ainda assim, FastAPI pegou alguma inspiração do Requests.

**Requests** é uma biblioteca para interagir com APIs (como um cliente), enquanto **FastAPI** é uma biblioteca para *construir* APIs (como um servidor).

Enquanto você e seu _crush_ :heart_eyes: estão ocupados não permitindo que ninguém passe a frente e pegue seus hambúrgueres assim que estiverem prontos, você não pode dar atenção ao seu _crush_ :heart_eyes:.

---

"*Honestamente, o que você construiu parece super sólido e rebuscado. De muitas formas, eu queria que o **Hug** fosse assim - é realmente inspirador ver alguém que construiu ele.*"

## Construindo uma Imagem Docker com um Arquivo Único FastAPI

Se seu FastAPI for um único arquivo, por exemplo, `main.py` sem um diretório `./app`, sua estrutura de arquivos poderia ser assim:

```
.
├── Dockerfile
├── main.py
└── requirements.txt
```

Então você só teria que alterar os caminhos correspondentes para copiar o arquivo dentro do `Dockerfile`: