200
Ugh ... (309, 400, 403, 409, 415, 422) ... muitas respostas tentando adivinhar, argumentar e padronizar qual é o melhor código de retorno para uma solicitação HTTP bem - sucedida, mas uma falha na chamada REST .
É errado misturar códigos de status HTTP e códigos de status REST.
No entanto, vi muitas implementações misturando-as e muitos desenvolvedores podem não concordar comigo.
Os códigos de retorno HTTP estão relacionados a HTTP Requestele próprio. Uma chamada REST é feita usando uma solicitação do Hypertext Transfer Protocol e funciona em um nível mais baixo do que o próprio método REST invocado. REST é um conceito / abordagem e sua saída é um resultado comercial / lógico , enquanto o código de resultado HTTP é um transporte .
Por exemplo, retornar "404 Não encontrado" quando você chama / users / é confuso, porque pode significar:
- O URI está errado (HTTP)
- Nenhum usuário encontrado (REST)
"403 Proibido / Acesso Negado" pode significar:
- É necessária permissão especial. Os navegadores podem lidar com isso perguntando ao usuário / senha. (HTTP)
- Permissões de acesso incorretas configuradas no servidor. (HTTP)
- Você precisa estar autenticado (REST)
E a lista pode continuar com 'Erro no servidor 500 "(um erro HTTP HTTP do Apache / Nginx ou um erro de restrição de negócios no REST) ou outros erros HTTP etc.
No código, é difícil entender qual foi o motivo da falha, uma falha HTTP (transporte) ou uma falha REST (lógica).
Se a solicitação HTTP foi fisicamente executada com sucesso, ela sempre deve retornar o código 200, independentemente dos registros encontrados ou não. Porque o recurso URI foi encontrado e foi tratado pelo servidor HTTP. Sim, pode retornar um conjunto vazio. É possível receber uma página da web vazia com 200 como resultado HTTP, certo?
Em vez disso, você pode retornar o código HTTP 200 com algumas opções:
- objeto "error" no resultado JSON se algo der errado
- Matriz / objeto JSON vazio se nenhum registro encontrado
- Um sinalizador de resultado / sucesso booleano em combinação com as opções anteriores para uma melhor manipulação.
Além disso, alguns provedores de Internet podem interceptar suas solicitações e retornar um código HTTP 404. Isso não significa que seus dados não foram encontrados, mas há algo errado no nível do transporte.
Do Wiki :
Em julho de 2004, o provedor de telecomunicações do Reino Unido BT Group implantou o sistema de bloqueio de conteúdo Cleanfeed, que retorna um erro 404 a qualquer solicitação de conteúdo identificado como potencialmente ilegal pela Internet Watch Foundation. Outros ISPs retornam um erro "proibido" de HTTP 403 nas mesmas circunstâncias. A prática de empregar erros 404 falsos como forma de ocultar a censura também foi relatada na Tailândia e na Tunísia. Na Tunísia, onde a censura era severa antes da revolução de 2011, as pessoas tomaram conhecimento da natureza dos falsos erros 404 e criaram um personagem imaginário chamado "Ammar 404", que representa "o censor invisível".
Por que não simplesmente responder com algo assim?
{
"result": false,
"error": {"code": 102, "message": "Validation failed: Wrong NAME."}
}
O Google sempre retorna 200 como código de status na API de geocodificação, mesmo que a solicitação falhe logicamente: https://developers.google.com/maps/documentation/geocoding/intro#StatusCodes
O Facebook sempre retorna 200 para solicitações HTTP bem-sucedidas, mesmo se a solicitação REST falhar: https://developers.facebook.com/docs/graph-api/using-graph-api/error-handling
É simples, os códigos de status HTTP são para solicitações HTTP. A API REST é sua, defina seus códigos de status.