Integração de API com Front, quem deve lidar com os erros?

[victorsilent]

Olar a todos, esses dias entrei numa discussão com uns amigos (back vs front) em que discordamos sobre quem deveria mandar a mensagem de erro ao ter um request respondido.
As duas posições foram:
1 - Em casos simplórios (forms onde apenas um campo seria unique no banco) o back deveria apenas retornar o código do http e apenas com isso o front deveria passar ao usuário que algo deu errado ali, EX: deu 404, então o login e senha estão incorretos.
2 - Mesmo em casos simplórios o back deveria retornar além do código de erro, uma mensagem informando o que aconteceu com a requisição. Ex: deu 404, no corpo da response vem {error: "Login ou senha inválidos"}

Eu concordo com o caso 1 em algumas situações, mas acredito que o caso 2 seria o caso mais correto e que iria abranger 99% dos projetos. Queria saber de vocês como tratam essa questão da criação dos erros? Responsabilidade do back ou do front?

[kivervinicius]

Uma API sempre deve tratar de forma mais clara os retornos, pois imagina por exemplo que esta API será implementada em varias tecnologias diferentes (exemplo android, ios e web), você terá que ter uma versão de mensagem em cada tecnologia? e se você errar uma letra? não é muito mais fácil corrigir na API onde você corrige e já atinge a todos?

Bem esta é minha opinião.

[fredmosc]

Olá, não tem um jeito realmente certo, o back deve retornar sim status http e, se for o caso alguma mensagem mais amigavel, mas isso deve ser levado em consideração caso-a-caso. Por exemplo, se alguém está inserindo um conteúdo duplicado no banco, um simples http stauts 409 (conflict) já resolve. Agora em outros casos a API deve sim retornar uma mensagem de erro clara do que houve (validação de campos etc) Até pq o front deve tratar de maneiras diferentes dependendo da plataforma (web, mobile etc) um comportamento web não necessariamente será o mesmo no mobile. Mas tudo isso deve ser definido na Arquitetura do software, antes do desenvolvimento, deve ficar claro a todos os desenvolvedores o padrão escolhido Em seg, 5 de mar de 2018 às 09:27, João Victor <[email protected]> escreveu:

Olar a todos, esses dias entrei numa discussão com uns amigos (back vs front) em que discordamos sobre quem deveria mandar a mensagem de erro ao ter um request respondido. As duas posições foram: 1 - Em casos simplórios (forms onde apenas um campo seria unique no banco) o back deveria apenas retornar o código do http e apenas com isso o front deveria passar ao usuário que algo deu errado ali, EX: deu 404, então o login e senha estão incorretos. 2 - Mesmo em casos simplórios o back deveria retornar além do código de erro, uma mensagem informando o que aconteceu com a requisição. Ex: deu 404, no corpo da response vem {error: "Login ou senha inválidos"} Eu concordo com o caso 1 em algumas situações, mas acredito que o caso 2 seria o caso mais correto e que iria abranger 99% dos projetos. Queria saber de vocês como tratam essa questão da criação dos erros? Responsabilidade do back ou do front? — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <https://github.com/frontendbr/forum/issues/970>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AJB79eItrFkQLPUjufSnWifjISwdCMzRks5tbS9PgaJpZM4ScNCz> .

-- Att, FM <https://about.me/fredmosc?promo=email_sig&utm_source=product&utm_medium=email_sig&utm_campaign=edit_panel&utm_content=thumb> Frederick Moschkowich about.me/fredmosc <https://about.me/fredmosc?promo=email_sig&utm_source=product&utm_medium=email_sig&utm_campaign=edit_panel&utm_content=thumb>

[tarciozemel]

http://desenvolvimentoparaweb.com/miscelanea/api-restful-melhores-praticas-parte-2/#errors

[mahenrique94]

Acho que a API deve retornar erros e claros, assim, o front consegue exibir essas mensagens para o usuário.

E sobre validar dados de entrada, eu gosto de validar em ambos os lados, caso o usuário burle o navegador, o back esta pronto para acessar.

[gspaiva]

Na minha opinião a API deveria, pelo menos na maioria dos casos, retornar os erros para o front-end de modo que o erro não fique genérico demais. Já que o erro ocorreu a nível de API, a mesma deveria retornar o erro e seu status, claro que tem erros que não devem ser retornados para o usuário final, mas aí vai de caso a caso. Mas eu acho que o que mais devemos nos preocupar é a experiência que o usuário terá na aplicação, acho que retornos muito genéricos não é algo que traz valor para o usuário final.

[Cleysonlb]

• Complementando o que ja foi dito a cima, o backend tem que retornar sim o código juntamente com uma mensagem, como foi dito, e se essa API for consumida em lugares diferentes?!

• Sobre validação, o ideal seria ter nos dois, mas caso precise optar, opte pela validação no backend (na model) pq garante que uma transação não será feita caso esbarre na validação, algo que facilmente poderia ser burlada no front.

[victorsilent]

Pois é, meu ponto é um pouco da união dos dois, pois acredito que em vários casos da sim pra retornar apenas um 404, um 409 e ta tudo certo, mas tem coisas que não se da pra verificar no front, e foi isso que entramos em discussão na hora, alguns forms possuem mais de um campo que deve ser único, não seria viável criar sei lá, 3 rotas, uma para cada campo, para fazer essa validação assíncrona. Óbvio, existem inúmeras formas de se fazer isso, mas como disse, acho que retornar o erro ocorrido seria a forma mais ampla de atender a todos.

[safirelauene]

Eu acredito que a melhor forma seja ter o tratamento do erro em ambos os lados.
Se, por exemplo, em um formulário o campo 'telefone' é obrigatório então o front pode exibir uma mensagem indicando que aquele campo precisa ser preenchido até mesmo antes de submeter o formulário mas o back também deve retornar um status e uma mensagem de erro indicando que o campo deve ser preenchido, pois pode ser que o browser seja burlado ou a api esteja sendo utilizada ou irá ser usada em outras aplicações.
Há também outros cenários onde eu acho que a validação pode ocorrer somente no front, em casos que não tratem do modelo ou regra de negócio, como por exemplo, submeter um formulário com um campo e-mail garantindo que o e-mail seja enviado pra api com formato válido.

[ninetails]

Aproveitando a thread, gostaria de instaurar um mini caos discutir uma dúvida praqueles que defendem trazer o http code:

retornar 404 ao não encontrar algo no banco de dados?

pessoalmente acho errado pela ambiguidade que pode trazer por um erro de preenchimento da url da api, por exemplo, mas ainda tenho essa dúvida/discussão

[bernardodiasc]

@ninetails é uma boa questão. As opiniões são divergentes aqui https://stackoverflow.com/questions/11746894/what-is-the-proper-rest-response-code-for-a-valid-request-but-an-empty-data

Particularmente acho que 200 com uma mensagem adequada faz muito mais sentido. Porém 404 serviria caso a página em questão devesse retornar baseando-se em algum conteúdo.

Por exemplo, no link meusite.com/algum-blog-post, usando um sistema que gera as rotas no server, vai procurar conteúdo de algum-blog-post e ele não existe no banco de dados, esse seria um caso de página não encontrada, parecendo correto retornar 404.

Mas para outros casos onde o conteúdo não encontrado não refere-se com a página/rota, então concordo ser inadequado usar 404.

[luizbills]

retornar 404 ao não encontrar algo no banco de dados?

Eu penso que deve retornar 404 no header e sempre retornar um parametro informando que teve erro (um erro mais humanizado). Eu por exemplo, não gosto de checar qual erro especifico está no header, apenas vejo se é um valor maior que 300. Então pela resposta da API, eu verifico que erro foi.

Até porque se der realmente um 404 (uma url inválida), você provavelmente nem vai receber uma resposta válida da api.