DROPS I - Status Code 500

A sua aplicação fazendo você passar vergonha!

Uma das coisas que ao meu ver faz um excelente profissional é sua atenção ao detalhes e ter maestria nisso é uma coisa para poucos. Você não precisa ser o mais perfeccionista e mais cuidadoso da terra, para adotar algumas boas práticas e evitar alguns erros.

O porque do erro 500

Durante a comunicação de aplicação com back-end os status codes são essenciais para sabermos o que realmente aconteceu em uma aplicação e o erro 500 é quase um padrão para coisas que deram erro e não houve tratamento.

Segundo a definição da W3C, o erro 500 é para retornar no seguinte caso.

500 Internal Server Error
The server encountered an unexpected condition which prevented it from fulfilling the request.
500 Erro interndo do servidor
O servidor encontrou uma condição inesperada que impede ele de completar a requisição

A falta de trativa, algo inesperado geralmente acontece após a sua aplicação cair completamente e não ter nada para responder. Algumas pessoas ao programar contam com ferramentas que reiniciam rapidamente a instancia da sua API, achando que podem deixar esses erros acontecerem sem problemas.

Mas isso tem um efeito colateral bem ruim, por exemplo, se uma tratativa que realmente impede uma requisição de ser processada e que deveria ser analisada, perde-se a importancia, com diversos erros 500 notificados nos logs da aplicação.

Boas práticas ao tratar erros em API

Algumas APIs consultam outras APIs e no tempo dessas requisições ocorrem erros que impedem o servidor de responder uma requisição. Só a descrição desse problema já parece algo para retornar um status code 500, mas se olharmos com mais atenção é algo que deveria ser tratado no back-end, sem devolver um status code 500.

Nesse caso seu serviço poderia retornar um 503 ao invés de um status code 500, afinal um serviço interno não está disponivel.

Tratar erros conhecidos da sua aplicação com o status code correto, ajuda as aplicações informarem ainda melhor os usuários sobre os erros. Uma regra que gosto de usar ao definir retorno de erros para APIs é usar a regra que já está no próprio W3c.

Espero que isso te guie para ter respostas e mensagens de erros melhores em suas APIs. O erro 500 pode até acontecer, mas lembre que ele deveria ser a excessão.