Avalie se a maneira correta de lidar com erros em uma API RESTful inclui as seguintes ações: I. Retornar um código de status 200 OK com uma mensagem de erro no corpo da resposta. II. Retornar um código de status 400 Bad Request com uma mensagem de erro no corpo da resposta. III. Retornar um código de status 500 Internal Server Error com uma mensagem de erro no corpo da resposta. IV. Retornar um código de status 200 OK com uma mensagem de erro no cabeçalho de resposta. V. Retornar um código de status 202 Accepted com uma mensagem de erro no corpo da resposta. Estão corretas as ações
- A)I e II, apenas.
Errada, porque 200 OK com mensagem de erro contradiz a semântica do HTTP e não é a forma adequada de sinalizar falha.
- B)II e III, apenas.
Certa, porque 400 Bad Request e 500 Internal Server Error são códigos apropriados para erros, com detalhamento no corpo da resposta.
- C)III e IV, apenas.
Errada, porque 500 pode ser usado com erro no corpo, mas 200 OK com mensagem de erro no cabeçalho continua incorreto.
- D)IV e V, apenas.
Errada, porque 200 OK não deve carregar erro, e 202 Accepted indica processamento aceito, não falha.
- E)I, II, III, IV e V.
Errada, porque mistura códigos de sucesso ou processamento com mensagens de erro, o que fere a lógica dos status HTTP.
Gabarito: B
Em APIs RESTful, o status HTTP existe justamente para dizer, de forma rápida, se a requisição deu certo ou não. Por isso, quando ocorre um problema no lado do cliente, o comum é usar códigos da faixa 4xx, como o 400 Bad Request, e, quando a falha está no servidor, códigos da faixa 5xx, como o 500 Internal Server Error. A mensagem de erro pode vir no corpo da resposta, porque é ali que normalmente você detalha o que aconteceu e como o cliente pode ajustar a chamada. A ideia de devolver 200 OK junto com uma mensagem de erro costuma confundir o cliente, porque o protocolo está dizendo “deu tudo certo”, enquanto o conteúdo está dizendo o contrário. Isso quebra a semântica HTTP e atrapalha integrações, monitoramento e tratamento automático de falhas. O mesmo vale para colocar erro no cabeçalho com status 200: o problema continua escondido atrás de um sucesso falso. Já o 202 Accepted não é código de erro. Ele indica que a requisição foi recebida e aceita para processamento futuro, mas ainda não concluída. Então ele serve para cenários assíncronos, não para sinalizar falha. Em provas, a FGV gosta de cobrar justamente essa leitura semântica dos status HTTP: cada código comunica um tipo de resultado, e o corpo complementa essa informação, não substitui o status. Assim, estão corretas apenas as ações II e III, porque 400 representa erro de requisição do cliente e 500 representa erro interno do servidor, ambos podendo trazer uma mensagem de erro no corpo da resposta.