* Validar que existe um `item_id` no path para requisições `GET` e `PUT`.
* Validar que `item_id` é do tipo `int` para requisições `GET` e `PUT`.
    * Se não for, o cliente verá um erro útil e claro.
* Verificar se existe um parâmetro query opcional nomeado como `q` (como em `http://127.0.0.1:8000/items/foo?q=somequery`) para requisições `GET`.
    * Como o parâmetro `q` é declarado com `= None`, ele é opcional.

# Usar antigos códigos de status de erro de autenticação 403 { #use-old-403-authentication-error-status-codes }

Antes da versão `0.122.0` do FastAPI, quando os utilitários de segurança integrados retornavam um erro ao cliente após uma falha na autenticação, eles usavam o código de status HTTP `403 Forbidden`.

Validation errors:
Field: ('path', 'item_id'), Error: Input should be a valid integer, unable to parse string as an integer
```

### Sobrescreva o manipulador de erro `HTTPException` { #override-the-httpexception-error-handler }

Do mesmo modo, você pode sobrescrever o `HTTPException`.

Por exemplo, você pode querer retornar uma *response* em *plain text* ao invés de um JSON para os seguintes erros:

porque o parâmetro de path `item_id` tinha o valor `"foo"`, que não é um `int`.

O mesmo erro apareceria se você fornecesse um `float` em vez de um `int`, como em: [http://127.0.0.1:8000/items/4.2](http://127.0.0.1:8000/items/4.2)

/// check | Verifique
Então, com a mesma declaração de tipo do Python, o **FastAPI** fornece validação de dados.

Observe que o erro também declara claramente exatamente o ponto onde a validação não passou.

///

Agora, obtenha os dados do usuário do banco de dados (falso), usando o `username` do campo do formulário.

Se não existir tal usuário, retornaremos um erro dizendo "Incorrect username or password".

Para o erro, usamos a exceção `HTTPException`:

{* ../../docs_src/security/tutorial003_an_py310.py hl[3,79:81] *}

### Confira a senha { #check-the-password }

Caso um cliente tente enviar informações adicionais, ele receberá um retorno de **erro**.

Por exemplo, se o cliente tentar enviar os campos de formulário:

* `username`: `Rick`
* `password`: `Portal Gun`
* `extra`: `Mr. Poopybutthole`

Ele receberá um retorno de erro informando-o que o campo `extra` não é permitido:

```json
{
    "detail": [
        {

<span style="color: green;">INFO</span>:     Uvicorn running on http://127.0.0.1:8000 (Press CTRL+C to quit)
```

</div>

Então, se você acessar as URLs em `/openapi.json`, `/docs` ou `/redoc`, você receberá apenas um erro `404 Not Found` como:

```JSON
{
    "detail": "Not Found"
}

Deste modo, ao utilizar `secrets.compare_digest()` no código de sua aplicação, ela estará a salvo contra toda essa gama de ataques de segurança.

### Retorne o erro { #return-the-error }

        handler -->> client: resposta de erro HTTP
    end
    dep ->> operation: Executar dependência, e.g. sessão de BD
    opt raise
        operation -->> dep: Lançar exceção (e.g. HTTPException)
        opt handle
            dep -->> dep: Pode capturar exceções, lançar uma nova HTTPException, lançar outras exceções
        end
        handler -->> client: resposta de erro HTTP
    end

* **Validar** os dados retornados.
    * Se os dados forem inválidos (por exemplo, se estiver faltando um campo), significa que o código do *seu* aplicativo está quebrado, não retornando o que deveria, e retornará um erro de servidor em vez de retornar dados incorretos. Dessa forma, você e seus clientes podem ter certeza de que receberão os dados e o formato de dados esperados.
* Adicionar um **JSON Schema** para a resposta, na *operação de rota* do OpenAPI.