Retornar 200 com sucess = false ou retornar 4xx?
Como vocês costumam retornar para o front em um cenario na qual a requisição acertou o endpoint, porém, parou em alguma validação?
Como vocês costumam retornar para o front em um cenario na qual a requisição acertou o endpoint, porém, parou em alguma validação?
O status HTTP serve justamente pra não precisar conhecer nada dentro do body da response, use-o com sabedoria.
Já peguei casos em que a API devolvia 200 com um body que tinha:
{
success: true,
sucess: true
}
Porque alguém tinha escrito errado e não dava pra voltar atrás porque já tinha passado muito tempo... sistemas legado.
Opa, depende muito do cenario em que se encontra essa parada. se for por conta da queda da sua pagina e ou endereço nao reconhecido/inexistente geralmente retornam o 404 - not fauld, geralmente tem uma lista de protocolo para te responder:
Link: https://developer.mozilla.org/pt-BR/docs/Web/HTTP/Status
400- bad request e no response retorno uma mensagem informando qual validação não passou.
Quando eu recebo status 200 ( NEM QUERO SABER DO RESTO ), o ideal é mandar status 4xx de erro, para que possa ser tratado do lado do requisitante
Para quem trabalha com sistemas legados, poderiam realizar alguns testes
Cada caso é um caso, cada linguagem é uma linguagem
Em php é possivel retornar um status code diferente de 200, e mesmo assim retornar um conteudo dentro do body de uma request
isso varia tanto de quem envia como quem recebe, por isso é necessario varios testes, mas um sistema q recebe um erro 400, e verifica no body q existe um success: false não deveria quebrar
Seria uma redundancia ter um success: false e um status code diferente de 200, sim. Porém no caso de sistemas que já estão em produção é algo que ter ajuda.
Neste caso sugiro retornar um 400
, pois no código você vai poder capturar isso e utilizar uma lógica separada do caminho de sucesso.
No TabNews fazemos isso, onde eu acabei de tentar responder o seu comentário sem body
e o backend respondeu com um 400
e com isso podemos formatar o campo com uma indicação de erro:
E se você considerar que deve retornar 200
se acertou um endpoint, a maioria dos retornos vai ser 200
, incluindo quando o endpoint gerar um erro interno.
Recomendo dar uma lida aqui: https://developer.mozilla.org/pt-BR/docs/Web/HTTP/Status
Normalmente evito usar 200 para indicar falha, acaba ficando confuso. Alguns projetos que trabalhei usaram como padrão retornar o erro 500 e no próprio link diz que os erros 5xx são respostas de erro do servidor.
Como dito em alguns comentarios acima, o status code do HTTP serve para você indicar o que aconteceu, tanto para as aplicações como para os navegadores. E existem os grupos de Status code separados em "Continue", respostas de sucesso, redirecionamentos, problemas no lado do client, e problemas no lado do servidor. Veja a baixo como é essa separação.
Dentro de cada uma dessas familias temos os codigos, como por exemplo 201 para requisições de create, 200 para get, todas com sucesso. Se acessar uma pagina que não existe, ele retorna um 404, pois o usuario errou a pagina. Um site muito util e divertido para aprender esses status code é o http.cat.
Para saber o que um status code faz, basta digitar http.cat + status_code
Cara, sendo bem sincero, onde eu trabalho às vezes recebemos 200 com sucess = false e geralmente gera incerteza acerca do resultado, além de deixar mais difícil validar a resposta - isso no back end. Ainda assim, acredito que para fins de padronização (se fizer sentido no seu negócio) vale mais a pena retornar 4xx.
não faz sentido @gsouza pois você esta falando que deu sucesso na chamada porém dentro do body você diz que deu erro, na minha opnião para isso que se usa o 400 até mesmo para auditoria , logs, observabilidade .
A não ser que você use Graphql