### A response resultante { #the-resulting-response }
Se o cliente faz uma requisição para `http://example.com/items/foo` (um `item_id``"foo"`), esse cliente receberá um HTTP status code 200, e uma resposta JSON:
```
```JSON
{
"item": "The Foo Wrestlers"
}
@ -71,7 +70,7 @@ Esses tipos de dados são manipulados automaticamente pelo **FastAPI** e convert
Há certas situações em que é bastante útil poder adicionar headers customizados no HTTP error. Exemplo disso seria adicionar headers customizados para tipos de segurança.
@ -81,7 +80,7 @@ Mas caso você precise, para um cenário mais complexo, você pode adicionar hea
## Instalando manipuladores de exceções customizados
## Instale manipuladores de exceções customizados { #install-custom-exception-handlers }
Você pode adicionar manipuladores de exceção customizados com <ahref="https://www.starlette.dev/exceptions/"class="external-link"target="_blank">a mesma seção de utilidade de exceções presentes no Starlette</a>
@ -109,7 +108,7 @@ Você também pode usar `from starlette.requests import Request` and `from starl
///
## Sobrescreva o manipulador padrão de exceções
## Sobrescreva os manipuladores de exceções padrão { #override-the-default-exception-handlers }
**FastAPI** tem alguns manipuladores padrão de exceções.
@ -117,12 +116,16 @@ Esses manipuladores são os responsáveis por retornar o JSON padrão de respost
Você pode sobrescrever esses manipuladores de exceção com os seus próprios manipuladores.
## Sobrescreva exceções de validação da requisição
### Sobrescreva exceções de validação da requisição { #override-request-validation-exceptions }
Quando a requisição contém dados inválidos, **FastAPI** internamente lança para o `RequestValidationError`.
E também inclui um manipulador de exceções padrão para ele.
Para sobrescrevê-lo, importe o `RequestValidationError` e use-o com o `@app.exception_handler(RequestValidationError)` para decorar o manipulador de exceções.
O manipulador de exceções receberá um `Request` e a exceção.
Se você for ao `/items/foo`, em vez de receber o JSON padrão com o erro:
@ -150,15 +153,15 @@ path -> item_id
value is not a valid integer (type=type_error.integer)
```
### `RequestValidationError` vs `ValidationError`
####`RequestValidationError` vs `ValidationError` { #requestvalidationerror-vs-validationerror }
/// warning | Aviso
/// warning | Atenção
Você pode pular estes detalhes técnicos caso eles não sejam importantes para você neste momento.
///
`RequestValidationError` é uma subclasse do <ahref="https://docs.pydantic.dev/latest/#error-handling"class="external-link"target="_blank">`ValidationError`</a> existente no Pydantic.
`RequestValidationError` é uma subclasse do <ahref="https://docs.pydantic.dev/latest/concepts/models/#error-handling"class="external-link"target="_blank">`ValidationError`</a> existente no Pydantic.
**FastAPI** faz uso dele para que você veja o erro no seu log, caso você utilize um modelo de Pydantic em `response_model`, e seus dados tenham erro.
@ -168,6 +171,8 @@ E assim deve ser porque seria um bug no seu código ter o `ValidationError` do P
E enquanto você conserta o bug, os clientes / usuários não deveriam ter acesso às informações internas do erro, porque, desse modo, haveria exposição de uma vulnerabilidade de segurança.
### Sobrescreva o manipulador de erro `HTTPException` { #override-the-httpexception-error-handler }
Do mesmo modo, você pode sobreescrever o `HTTPException`.
Por exemplo, você pode querer retornar uma *response* em *plain text* ao invés de um JSON para os seguintes erros:
@ -197,7 +204,7 @@ Tente enviar um item inválido como este:
}
```
Você receberá uma *response* informando-o de que a data é inválida, e contendo o *body* recebido:
Você receberá uma *response* informando-o de que os dados são inválidos, e contendo o *body* recebido:
```JSON hl_lines="12-15"
{
@ -218,27 +225,27 @@ Você receberá uma *response* informando-o de que a data é inválida, e conten
}
```
#### O `HTTPException` do FastAPI vs o `HTTPException` do Starlette.
#### O `HTTPException` do FastAPI vs o `HTTPException` do Starlette { #fastapis-httpexception-vs-starlettes-httpexception }
O **FastAPI** tem o seu próprio `HTTPException`.
E a classe de erro `HTTPException` do **FastAPI** herda da classe de erro do `HTTPException` do Starlette.
A diferença entre os dois é a de que o `HTTPException` do **FastAPI** permite que você adicione *headers* que serão incluídos nas *responses*.
Esses *headers* são necessários/utilizados internamente pelo OAuth 2.0 e também por outras utilidades de segurança.
A única diferença é que o `HTTPException` do **FastAPI** aceita qualquer dado que possa ser convertido em JSON para o campo `detail`, enquanto o `HTTPException` do Starlette aceita apenas strings para esse campo.
Portanto, você pode continuar lançando o `HTTPException` do **FastAPI** normalmente no seu código.
Porém, quando você registrar um manipulador de exceção, você deve registrá-lo através do `HTTPException` do Starlette.
Dessa forma, se qualquer parte do código interno, extensão ou plug-in do Starlette lançar o `HTTPException`, o seu manipulador de exceção poderá capturar esse lançamento e tratá-lo.
Dessa forma, se qualquer parte do código interno, extensão ou plug-in do Starlette lançar um `HTTPException` do Starlette, o seu manipulador poderá capturar e tratá-lo.
Neste exemplo, para poder ter ambos os `HTTPException` no mesmo código, a exceção do Starlette é renomeada para `StarletteHTTPException`:
```Python
from starlette.exceptions import HTTPException as StarletteHTTPException
```
### Re-use os manipulares de exceção do **FastAPI**
### Reutilize os manipuladores de exceção do **FastAPI** { #reuse-fastapis-exception-handlers }
Se você quer usar a exceção em conjunto com o mesmo manipulador de exceção *default* do **FastAPI**, você pode importar e re-usar esses manipuladores de exceção do `fastapi.exception_handlers`:
Rafael de Oliveira Marques
8 months ago