¿Qué código de respuesta de estado HTTP debería usar si a la solicitud le falta un parámetro requerido?

Estoy pensando 412 (precondición fallida) pero puede haber un mejor estándar?

El estado 422 parece ser el más apropiado según la especificación .

El código de estado 422 (Entidad no procesable) significa que el servidor entiende el tipo de contenido de la entidad de solicitud (por lo tanto, un código de estado 415 (Tipo de medio no admitido) es inapropiado) y la syntax de la entidad de solicitud es correcta (por lo tanto, 400 (Solicitud incorrecta) el código de estado es inapropiado) pero no pudo procesar las instrucciones contenidas. Por ejemplo, esta condición de error puede ocurrir si un cuerpo de solicitud XML contiene instrucciones XML bien formadas (es decir, sintácticamente correctas) pero semánticamente erróneas.

Afirman que el xml malformado es un ejemplo de mala syntax (llamando a un 400). Una cadena de consulta mal formada parece análoga a esto, por lo que 400 no parece apropiado para una cadena de consulta bien formada a la que le falta un parámetro.

ACTUALIZAR @DavidV señala correctamente que esta especificación es para WebDAV, no para el núcleo HTTP. Pero algunas API populares que no son WebDAV están usando 422 de todos modos, por falta de un mejor código de estado ( ver esto ).

No estoy seguro de que haya un estándar establecido, pero hubiera usado 400 Bad Request :

La solicitud no pudo ser entendida por el servidor debido a una syntax mal formada. El cliente NO DEBE repetir la solicitud sin modificaciones.

La API de WCF en .NET maneja los parámetros que faltan devolviendo un error de HTTP 404 “Endpoint Not Found”, cuando se utiliza el webHttpBinding .

El 404 Not Found puede tener sentido si considera el nombre de su método de servicio web junto con su firma de parámetro. Es decir, si expone un método de servicio web LoginUser(string, string) y solicita LoginUser(string) , este último no se encuentra.

Básicamente, esto significa que no se puede encontrar el método de servicio web que está llamando, junto con la firma del parámetro que ha especificado.

10.4.5 404 no encontrado

El servidor no ha encontrado nada que coincida con el URI de solicitud. No se indica si la condición es temporal o permanente.

La 400 Bad Request , como sugirió Gert , sigue siendo un código de respuesta válido, pero creo que normalmente se usa para indicar problemas de menor nivel. Se podría interpretar fácilmente como una solicitud HTTP mal formada, tal vez faltan encabezados HTTP no válidos o similares.

10.4.1 400 solicitud incorrecta

La solicitud no pudo ser entendida por el servidor debido a una syntax mal formada. El cliente NO DEBE repetir la solicitud sin modificaciones.

En uno de nuestros proyectos API, decidimos establecer un estado 409 para alguna solicitud, cuando no podemos llenarlo al 100% debido a la falta del parámetro.

El código de estado HTTP “409 Conflict” fue para nosotros una buena oportunidad porque su definición requiere incluir suficiente información para que el usuario reconozca el origen del conflicto.

Referencia: w3.org/Protocols/

Entonces, entre otras respuestas como 400 o 404, elegimos 409 para hacer cumplir la necesidad de revisar algunas notas en la solicitud y ayudar a configurar una nueva y correcta solicitud.

De cualquier forma, nuestro caso fue particular porque necesitamos enviar algunos datos si la solicitud no fue completamente correcta, y tenemos que exigir al cliente que mire el mensaje y comprenda qué fue lo que estuvo mal en la solicitud.

En general, si solo tenemos algunos parámetros faltantes, buscamos un 400 y una matriz de parámetros faltantes. Pero cuando necesitamos enviar más información, como un mensaje de caso particular y queremos estar más seguros de que el cliente se encargará de ello, le enviaremos un 409

Puede enviar un código de 400 solicitudes incorrectas. Es uno de los códigos de estado 4xx más generales, por lo que puede usarlo para significar lo que desea: el cliente está enviando una solicitud que le falta información / parámetros que su aplicación requiere para procesarla correctamente.

Normalmente utilizo 422 (entidad no procesable) si algo en los parámetros requeridos no coincidía con lo que requería el punto final API (como una contraseña demasiado corta) pero para un parámetro faltante iría a 406 (inaceptable).

A menudo uso un error 403 Forbidden. El razonamiento es que la solicitud fue entendida, pero no voy a hacer lo que se me pide (porque las cosas están mal). La entidad de respuesta explica qué es lo que está mal, de modo que si la respuesta es una página HTML, los mensajes de error están en la página. Si se trata de una respuesta JSON o XML, la información de error está allí.

Desde rfc2616 :

10.4.4 403 prohibido

El servidor entendió la solicitud, pero se niega a cumplirla.
La autorización no ayudará y la solicitud NO DEBE repetirse.
Si el método de solicitud no era HEAD y el servidor desea hacer
público por qué la solicitud no se ha cumplido, DEBERÍA describir el motivo de la negativa en la entidad. Si el servidor no desea que esta información esté disponible para el cliente, el código de estado 404
(No encontrado) se puede utilizar en su lugar.

Se podría argumentar que se debe utilizar un 404 Not Found debido a que no se pudo encontrar el recurso especificado.

Para los interesados, Spring MVC (3.x al menos) devuelve 400 en este caso, lo cual me parece incorrecto.

Probé varias URL de Google (accounts.google.com) y eliminé los parámetros necesarios, y generalmente devuelven un 404 en este caso.

Copiaría Google.

Me gustaría ir con un 403.

De RFC 2616 – Protocolo de transferencia de hipertexto – HTTP / 1.1

403 prohibido

El servidor entendió la solicitud, pero se niega a cumplirla. La autorización no ayudará y la solicitud NO DEBE repetirse. Si el método de solicitud no era HEAD y el servidor desea hacer público el motivo por el cual no se ha cumplido la solicitud, DEBERÍA describir el motivo de la negativa en la entidad. Si el servidor no desea poner esta información a disposición del cliente, se puede usar el código de estado 404 (No encontrado).

Debe describir el motivo de la falla en su respuesta. Si prefiere no hacerlo, solo use 404.