Mas o login do Facebook não tem suporte para OpenID Connect. Ele tem a própria implementação do OAuth2.

### OpenID (não "OpenID Connect")

Houve também uma especificação “OpenID”. Ela tentou resolver a mesma coisa que a **OpenID Connect**, mas não baseada em OAuth2.

Então, ela foi um sistema adicional completo.

Ela não é muito popular ou usada nos dias de hoje.

Isso é bastante similar ao caso do HTTP status code 200 (do 200 ao 299). Esses "200" status codes significam que, de algum modo, houve sucesso na requisição.

Os status codes na faixa dos 400 significam que houve um erro por parte do cliente.

Você se lembra de todos aqueles erros (e piadas) a respeito do "**404 Not Found**"?

## Use o `HTTPException`

## Dependências com `yield` e `except`

Se você capturar uma exceção com `except` em uma dependência que utilize `yield` e ela não for levantada novamente (ou uma nova exceção for levantada), o FastAPI não será capaz de identifcar que houve uma exceção, da mesma forma que aconteceria com Python puro:

//// tab | Python 3.9+

```Python hl_lines="15-16"
{!> ../../docs_src/dependencies/tutorial008c_an_py39.py!}
```

////

Você pega seus hambúrgueres e vai para a mesa com seu _crush_ :heart_eyes:.

Vocês comem os hambúrgueres, e o trabalho está terminado.

Não houve muita conversa ou flerte já que a maior parte do tempo foi gasto esperando os lanches na frente do balcão.

---

No entanto, pode haver casos em que escrevemos algum código que **trava todo o aplicativo**, fazendo com que o Uvicorn e o Python travem. 💥

E ainda assim, você provavelmente não gostaria que o aplicativo permanecesse inativo porque houve um erro em um lugar, você provavelmente quer que ele **continue em execução** pelo menos para as *operações de caminho* que não estão quebradas.

### Reiniciar após falha

Tenho evitado criar um novo framework por anos. Primeiramente tentei resolver todos os recursos cobertos pelo **FastAPI** utilizando muitos frameworks diferentes, plug-ins e ferramentas.

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

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

* Então ele retorna a **resposta**.

/// note | "Detalhes técnicos"

Se você tiver dependências com `yield`, o código de saída será executado *depois* do middleware.

Se houver alguma tarefa em segundo plano (documentada posteriormente), ela será executada *depois* de todo o middleware.

///

## Criar um middleware

```Python hl_lines="13  15  22  25"
{!../../docs_src/background_tasks/tutorial002.py!}
```

Neste exemplo, as mensagens serão gravadas no arquivo `log.txt` _após_ o envio da resposta.

Se houver uma consulta na solicitação, ela será gravada no log em uma tarefa em segundo plano.

E então outra tarefa em segundo plano gerada na _função de operação de caminho_ escreverá uma mensagem usando o parâmetro de caminho `email`.

///

Primeiro, criamos uma classe `GzipRequest`, que irá sobrescrever o método `Request.body()` para descomprimir o corpo na presença de um cabeçalho apropriado.

Se não houver `gzip` no cabeçalho, ele não tentará descomprimir o corpo.

Dessa forma, a mesma classe de rota pode lidar com requisições comprimidas ou não comprimidas.

```Python hl_lines="8-15"