para - http/1.1 200 ok
¿Qué código de respuesta de estado HTTP debo usar si a la solicitud le falta un parámetro requerido? (10)
Estoy pensando en 412 (Condición fallida), pero puede haber un mejor estándar?
A menudo utilizo un error 403 Prohibido. El razonamiento es que se entendió la solicitud, pero no voy a hacer lo que se me pide (porque las cosas están mal). La entidad de respuesta explica qué es incorrecto, por lo que si la respuesta es una página HTML, los mensajes de error están en la página. Si es una respuesta JSON o XML, la información del 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
Por qué no se ha cumplido con la solicitud, debe describir la razón 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.
El estado 422 parece más apropiado en base a la spec .
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 inadecuado), y la sintaxis de la entidad de solicitud es correcta (por lo tanto, un código de estado 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 un xml con formato incorrecto es un ejemplo de sintaxis incorrecta (que requiere 400). Una cadena de consulta mal formada parece ser 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.
ACTUALIZACIÓN @DavidV señala correctamente que esta especificación es para WebDAV, no para HTTP principal. Pero algunas API populares que no son de WebDAV están usando 422 de todos modos, por falta de un mejor código de estado ( ver esto ).
En uno de nuestros proyectos de API, decidimos establecer un estado 409 para alguna solicitud, cuando no podemos llenarlo al 100% debido a que falta el parámetro.
El Código de estado HTTP "409 Conflicto" fue para nosotros un buen intento porque su definición requiere incluir suficiente información para que el usuario reconozca el origen del conflicto.
Referencia: w3.org/Protocols/
Así que, entre otras respuestas, como 400 o 404, elegimos 409 para hacer cumplir la necesidad de revisar algunas notas en la solicitud de ayuda para configurar una solicitud nueva y correcta.
En cualquier caso, nuestro caso fue particular, ya que necesitamos enviar algunos vísperas de datos si la solicitud no fue completamente correcta, y necesitamos hacer que el cliente vea el mensaje y entienda qué fue lo que falló en la solicitud.
En general, si solo faltan algunos parámetros , vamos por 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 ocupará de ello, le enviamos un 409
La API de WCF en .NET maneja los parámetros faltantes devolviendo un error HTTP 404 "Punto final no encontrado", cuando se usa 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 significaría que no se puede encontrar el método del servicio web al que está llamando, junto con la firma del parámetro que especificó.
10.4.5 404 No encontrado
El servidor no ha encontrado nada que coincida con el URI de solicitud. No se da ninguna indicación de 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 nivel inferior. Fácilmente podría interpretarse como una solicitud HTTP mal formada, encabezados HTTP faltantes o no válidos, o similar.
10.4.1 400 mala solicitud
El servidor no pudo comprender la solicitud debido a una sintaxis mal formada. El cliente NO DEBE repetir la solicitud sin modificaciones.
Para aquellos interesados, Spring MVC (3.x al menos) devuelve un 400 en este caso, lo que 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.
Yo copiaría Google.
Por lo general, me dirijo a 422 (entidad no procesable) si algo en los parámetros requeridos no coincide con lo que requiere el punto final de la API (como una contraseña demasiado corta) pero para un parámetro faltante, obtendría 406 (inaceptable).
Puede enviar un código de 400 Solicitudes erróneas. Es uno de los códigos de estado 4xx de propósito más general, por lo que puede usarlo para referirse a lo que pretende: el cliente está enviando una solicitud que le falta información / parámetros que su aplicación requiere para procesarla correctamente.
Se podría argumentar que se debe usar un 404 Not Found ya que no se pudo encontrar el recurso especificado.
Yo iría 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 la solicitud no se ha cumplido, DEBE describir el motivo de la denegación en la entidad. Si el servidor no desea que esta información esté disponible para el cliente, se puede usar el código de estado 404 (No encontrado) en su lugar.
Debe describir la razón del fracaso en su respuesta. Si prefieres no hacerlo, solo usa 404.
No estoy seguro de que haya un estándar establecido, pero habría utilizado 400 Bad Request :
El servidor no pudo comprender la solicitud debido a una sintaxis mal formada. El cliente NO DEBE repetir la solicitud sin modificaciones.