Respostas:
O status 422 parece mais adequado com base nas especificações .
O código de status 422 (Entidade não processável) significa que o servidor entende o tipo de conteúdo da entidade solicitada (portanto, um código de status 415 (Tipo de mídia não suportado) é inadequado) e a sintaxe da entidade solicitada está correta (portanto, 400 (Solicitação incorreta) ) código de status é inadequado), mas não conseguiu processar as instruções contidas. Por exemplo, essa condição de erro pode ocorrer se um corpo de solicitação XML contiver instruções XML bem formadas (ou seja, sintaticamente corretas), mas semanticamente erradas.
Eles afirmam que o xml malformado é um exemplo de sintaxe incorreta (que exige 400). Uma string de consulta malformada parece análoga a isso, portanto 400 não parece apropriado para uma string de consulta bem formada, na qual está faltando um parâmetro.
UPDATE @DavidV indica corretamente que essa especificação é para WebDAV, não para HTTP principal. Mas algumas APIs populares que não são do WebDAV estão usando 422 de qualquer maneira, por falta de um código de status melhor ( veja isso ).
400é mais apropriado.
Não tenho certeza de que haja um padrão definido, mas eu teria usado 400 Solicitação incorreta , que a última especificação HTTP (de 2014) documenta da seguinte maneira :
6.5.1 400 Solicitação incorretaO código de status 400 (Solicitação incorreta) indica que o servidor não pode ou não processará a solicitação devido a algo que é considerado um erro do cliente (por exemplo, sintaxe de solicitação malformada, enquadramento de mensagem de solicitação inválida ou roteamento de solicitação enganoso).
400 Bad Requestdeve indicar problemas no nível do protocolo, não erros semânticos. Se vamos seqüestrar códigos de status HTTP para indicar erros no nível do aplicativo (e não no nível do protocolo), por que não percorrer todo o caminho e apenas usar 412?
A API do WCF no .NET manipula parâmetros ausentes, retornando um HTTP 404erro "Ponto de extremidade não encontrado", ao usar o webHttpBinding .
Isso 404 Not Foundpode fazer sentido se você considerar o nome do método de serviço da web juntamente com a assinatura do parâmetro. Ou seja, se você expõe um método de serviço da web LoginUser(string, string)e solicita LoginUser(string), o último não é encontrado.
Basicamente, isso significa que o método de serviço da Web que você está chamando, juntamente com a assinatura do parâmetro que você especificou, não pode ser encontrado.
10.4.5 404 não encontrado
O servidor não encontrou nada que corresponda ao Request-URI. Nenhuma indicação é dada sobre se a condição é temporária ou permanente.
O 400 Bad Request, como sugeriu Gert , continua sendo um código de resposta válido, mas acho que é normalmente usado para indicar problemas de nível inferior. Pode ser facilmente interpretado como uma solicitação HTTP malformada, talvez cabeçalhos HTTP ausentes ou inválidos ou semelhantes.
10.4.1 400 Solicitação incorreta
A solicitação não pôde ser entendida pelo servidor devido à sintaxe incorreta. O cliente não deve repetir o pedido sem modificações.
Em um de nossos projetos de API, decidimos definir um Status 409 para alguma solicitação, quando não podemos preenchê-lo totalmente em 100% por causa da falta de parâmetro.
O código de status HTTP "409 Conflict" foi uma boa tentativa para nós, pois sua definição exige a inclusão de informações suficientes para que o usuário reconheça a origem do conflito.
Referência: w3.org/Protocols/
Portanto, entre outras respostas, como 400 ou 404, escolhemos 409 para reforçar a necessidade de examinar algumas anotações na solicitação útil para configurar uma nova e correta solicitação.
De qualquer maneira, nosso caso foi particular, porque precisamos enviar alguns dados até a solicitação não estar completamente correta e forçar o cliente a olhar para a mensagem e entender o que havia de errado na solicitação.
Em geral, se tivermos apenas alguns parâmetros ausentes, optamos por 400 e uma matriz de parâmetros ausentes. Mas quando precisamos enviar mais algumas informações, como uma mensagem de caso em particular, e queremos ter mais certeza de que o cliente cuidará disso, enviamos uma mensagem 409
Normalmente eu escolho a 422 (entidade não processável) se algo nos parâmetros necessários não corresponder ao que o ponto de extremidade da API exigia (como uma senha muito curta), mas para um parâmetro ausente eu usaria a 406 (Inaceitável).
Accept-Language: de, indicando que ela aceitará apenas respostas em alemão, mas as únicas versões do documento solicitado que seu servidor está disponível estão em inglês ou francês.) A utilização para indicar um parâmetro ausente na solicitação está incorreta, de acordo com a definição em spec.
Para os interessados, o Spring MVC (pelo menos 3.x) retorna 400 neste caso, o que me parece errado.
Testei vários URLs do Google (accounts.google.com) e removi os parâmetros necessários, e eles geralmente retornam um 404 nesse caso.
Eu copiaria o Google.
Pode-se argumentar que a 404 Not Founddeve ser usado, pois o recurso especificado não pôde ser encontrado.
Costumo usar um erro 403 Proibido. O raciocínio é que a solicitação foi entendida, mas não vou fazer como solicitado (porque as coisas estão erradas). A entidade de resposta explica o que está errado; portanto, se a resposta for uma página HTML, as mensagens de erro estarão na página. Se for uma resposta JSON ou XML, as informações de erro estão lá.
De RFC2616 :
10.4.4 403 Proibido
O servidor entendeu a solicitação, mas está se recusando a atendê-la.
A autorização não ajudará e a solicitação NÃO DEVE ser repetida.
Se o método de solicitação não foi HEAD e o servidor deseja tornar
público o motivo pelo qual a solicitação não foi atendida, DEVE descrever o motivo da recusa na entidade. Se o servidor não desejar disponibilizar essas informações ao cliente, o código de status 404
(Não encontrado) poderá ser usado.
Authorization will not helpque o Twitter não deve enviar isso para credenciais inválidas do OAuth.
401 Unauthorized. No entanto, você pode entender por que não o fazem, se examinar as descrições dos documentos MDN desses dois códigos, que são muito semelhantes.
Apenas para usar o ASP.NET Core como referência ou exemplo, o ASP.NET Core permite organizar um controlador com ações, é assim que a ação "Detalhes" é exibida.
// GET: Cars/Details/5
public async Task<IActionResult> Details(int? id)
{
if (id == null)
{
return NotFound();
}
var car = await _context.Cars.FirstOrDefaultAsync(m => m.CarId == id);
if (car == null)
{
return NotFound();
}
return View(car);
}Se o parâmetro idnão estiver definido, ele retornará 404 Não encontrado.
Retorne um 404 - o que significa que o recurso não foi encontrado.
Tente editar um URL de um site que contenha um ID. Eu tentei alguns:
Todos retornam 404, porque esses desenvolvedores estão interpretando o padrão corretamente, o que a resposta aqui e muitas outras não são!
requestBody.
Eu iria com um 403.
Do RFC 2616 - Protocolo de transferência de hipertexto - HTTP / 1.1
403 Proibido
O servidor entendeu a solicitação, mas está se recusando a atendê-la. A autorização não ajudará e a solicitação NÃO DEVE ser repetida. Se o método de solicitação não foi HEAD e o servidor deseja tornar público o motivo pelo qual a solicitação não foi atendida, DEVE descrever o motivo da recusa na entidade. Se o servidor não desejar disponibilizar essas informações ao cliente, o código de status 404 (Não encontrado) poderá ser usado.
Você deve descrever o motivo da falha na sua resposta. Se você preferir não fazê-lo, use 404.