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

Respuestas:

388

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

El código de estado 422 (entidad no procesable) significa que el servidor comprende 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 sintaxis de la entidad de solicitud es correcta (por lo tanto, un 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 xml con formato incorrecto es un ejemplo de sintaxis incorrecta (que requiere 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 HTTP central. Pero algunas API populares que no son WebDAV están utilizando 422 de todos modos, por falta de un mejor código de estado ( ver esto ).

Kelvin
fuente
2
En mi opinión, usaría esto para cuando el valor en la cadena de consulta era incorrecto, no cuando había un valor adicional o faltaba un valor. es decir. Esperando un correo electrónico y su valor es '123123'
Derek Litz
2
Tiendo a pensar en los parámetros GET y POST como la firma del método de la ruta URL, por lo que 404 tiene sentido para mí. En una API RESTful destinada al consumo público, es prudente devolver los parámetros faltantes / adicionales. En el contexto de una URL, los parámetros de la cadena de consulta suelen ser importantes para identificar un recurso y los parámetros adicionales o faltantes representan un recurso que no existe, sin ningún supuesto. Por supuesto, hay compensaciones con la solidez al ser explícito, y los parámetros opcionales hacen que un recurso sea igualmente vulnerable al error silencioso. Luego está la usabilidad ...
Derek Litz
13
La especificación a la que se hace referencia es para WebDAV y no es la especificación estándar HTTP.
David V
1
@ Kelvin Gracias por señalar esa publicación de blog. Es útil ver que Twitter, por ejemplo, está usando 422. Creo que la respuesta podría ser mejor si aclaras que la especificación es WebDAV en la primera línea. Cuando leí tu respuesta por primera vez, pensé que te referías a la especificación estándar HTTP hasta que seguí el enlace.
David V
3
Vale la pena leerlo: bennadel.com/blog/… Tampoco usaría 422 para el parámetro perdido. Creo que 400es más apropiado
Zelphir Kaltstahl
184

No estoy seguro de que haya un estándar establecido, pero habría utilizado 400 Bad Request , que la última especificación HTTP (de 2014) documenta de la siguiente manera :

6.5.1. 400 Petición Incorrecta

El código de estado 400 (Solicitud incorrecta) indica que el servidor no puede o no procesará la solicitud debido a algo que se percibe como un error del cliente (por ejemplo, sintaxis de solicitud con formato incorrecto, enmarcado de mensaje de solicitud no válido o enrutamiento de solicitud engañoso).

Gert Grenander
fuente
65
400 Bad Requestestá destinado a indicar problemas a nivel de protocolo, no errores semánticos. Si vamos a secuestrar códigos de estado HTTP para indicar errores a nivel de aplicación (en lugar de a nivel de protocolo), ¿por qué no ir hasta el final y simplemente usar 412?
Matt Zukowski
36
La implementación de Google OAuth 1.0 está de acuerdo con esta respuesta. Se da una respuesta 400 cuando faltan o no se admiten los
Tom
1
@ matt-zukowski: "412: La condición previa dada en uno o más de los campos de encabezado de solicitud se evaluó como falsa cuando se probó en el servidor". de RFC2616 : si se trata de una POST, los parámetros están en el cuerpo de la solicitud y no en los campos de encabezado de solicitud. Técnicamente, el método GET envía sus parámetros en los encabezados de solicitud, pero prefiero tener algo de coherencia.
toong
66
@MattZukowski 400 es un código de estado de nivel de aplicación. Si observa la nueva redacción en la versión borrador de RFC 7231, verá eso. Desafortunadamente, la redacción de la última versión no es tan clara porque el autor de los últimos cambios también inventó 422.
Darrel Miller
99
@DarrelMiller tiene razón ( enlace directo ): "El código de estado 400 (Solicitud incorrecta) indica que el servidor no puede o no procesará la solicitud debido a algo que se percibe como un error del cliente (por ejemplo, sintaxis de solicitud con formato incorrecto, mensaje de solicitud no válido enmarcado o enrutamiento de solicitud engañoso) ". Dependiendo de las expectativas de semántica y extensibilidad (¿algún día será posible emitir una solicitud sin el parámetro?), Entonces solo 400 y 404 parecen apropiados en HTTP estándar. De lo contrario, invente un nuevo código para su API, pero no sobrecargue la semántica.
TNE
31

La API WCF en .NET maneja los parámetros faltantes al devolver un HTTP 404error "Punto final no encontrado", cuando se usa webHttpBinding .

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

Básicamente, esto significaría que no se puede encontrar el método de servicio web al que está llamando, junto con la firma de parámetros que especificó.

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.

El 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. Se podría interpretar fácilmente como una solicitud HTTP con formato incorrecto, tal vez encabezados HTTP faltantes o no válidos, o similar.

10.4.1 400 Solicitud incorrecta

El servidor no pudo entender la solicitud debido a una sintaxis incorrecta. El cliente NO DEBE repetir la solicitud sin modificaciones.

Daniel Vassallo
fuente
Esto es lo que CherryPy hace por defecto.
Derek Litz
¿Qué sucede cuando se maneja una solicitud de publicación en la que acepta un modelo y falta parte del modelo? En ese caso, no obtienes un 404. En cambio, obtienes un modelo que no es válido si no me equivoco y tienes que decidir qué hacer ahora.
Shane Courtrille
1
Esta interpretación parece una exageración y expresa un RPC en lugar de un pov REST. El URI es el identificador, existe y se ha encontrado. Lo que se envía en el cuerpo no es parte del identificador de recursos. 422 es más apropiado.
Jonás
404 es la respuesta correcta, ¡solo edite algunas URL en la web para encontrar el consenso!
jenson-button-event
8

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

BoltClock
fuente
7

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

El Código de estado HTTP "Conflicto 409" fue un buen intento para nosotros porque su definición requiere incluir suficiente información para que el usuario reconozca la fuente del conflicto.

Referencia: w3.org/Protocols/

Entonces, entre otras respuestas como 400 o 404, elegimos 409 para imponer la necesidad de revisar algunas notas en la solicitud que es útil para configurar una solicitud nueva y correcta.

De todos modos, nuestro caso fue particular porque necesitamos enviar algunos datos incluso si la solicitud no era completamente correcta, y debemos obligar al cliente a mirar el mensaje y comprender lo que está 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 eso, enviamos un 409

gabrielem
fuente
2
Esto es simplemente incorrecto. 409 es para problemas de concurrencia como @ MaximeGélinas señala O situaciones en las que un recurso ya está presente y no se permiten duplicados.
gimlichael
Según las especificaciones, "El código de estado 409 (Conflicto) indica que la solicitud no se pudo completar debido a un conflicto con el estado actual del recurso de destino". . Usarlo para un parámetro faltante es simplemente incorrecto; Ese es un tipo de error totalmente diferente.
Mark Amery
5

Por lo general, elijo 422 (entidad no procesable) si algo en los parámetros requeridos no coincide con lo que requería el punto final de la API (como una contraseña demasiado corta) pero para un parámetro faltante, iría por 406 (inaceptable).

Elad Meidar
fuente
8
Bueno, 406 Inaceptable se usa con el encabezado Aceptar (si el servidor no puede enviar una respuesta, el cliente lo entenderá). "El recurso identificado por la solicitud solo es capaz de generar entidades de respuesta que tienen características de contenido no aceptables de acuerdo con los encabezados de aceptación enviados en la solicitud". . Estoy atrapado con 422 ya que no hay una opción "correcta" con la especificación actual: - /
JakubKnejzlik
Usar 406 para esto está mal. Un código 406 no significa que la solicitud no sea aceptable; significa que no puede satisfacer la solicitud porque las respuestas que puede atender son las que el cliente consideraría inaceptables, según los encabezados de Aceptar que envió en la solicitud. (Por ejemplo, la solicitud incluida Accept-Language: de, que indica que solo aceptará respuestas en alemán, pero las únicas versiones del documento solicitado que su servidor tiene disponible están en inglés o francés). Usarlo para indicar que falta un parámetro en la solicitud es incorrecto, por la definición en espec.
Mark Amery
3

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 en general en este caso devuelven un 404.

Copiaría Google.

Neromancer
fuente
18
¡Porque Google lo hace no significa automáticamente que Google lo haga bien!
rve
44
Estoy de acuerdo, no necesariamente 'correcto' pero a veces lo que es correcto y lo que es razonable son dos cosas diferentes. De todos modos ... hasta el lector :)
Neromancer
Algunas API de Google devuelven un 400, por ejemplo, github.com/google/google-api-nodejs-client/issues/404
Dennis
lo que está mal (y por qué spring mvc no es compatible con
jax-
3

Se podría argumentar que se 404 Not Founddebe utilizar a ya que no se pudo encontrar el recurso especificado.

Rayo
fuente
3
Este es el comportamiento predeterminado de Java JAX-RS cuando un parámetro de consulta no se puede convertir al tipo de datos adecuado. Aunque no estoy de acuerdo con eso. Se encontró el recurso: los parámetros de consulta son para filtrar el recurso y uno de los filtros recibió un valor inaceptable. Creo que esto coincide con 422 Entidad no procesable más cercana y 400 Solicitud incorrecta segunda más cercana.
Ryan
¡es el comportamiento predeterminado de jax-rs porque es el comportamiento correcto!
jenson-button-event
El uso de un 404 es razonable cuando el parámetro de cadena de consulta está destinado a identificar un recurso, se le dio un valor, pero ese valor no corresponde a un recurso que existe, por ejemplo, si está solicitando example.com/show-user -profile? user_id = 123 y el usuario 123 no existe. Pero eso no es de lo que se pregunta esta pregunta; se trataba del escenario donde un parámetro requerido se omite por completo. No veo cómo eso corresponde a un recurso específico que no se encuentra.
Mark Amery
2

A menudo uso un error prohibido 403. El razonamiento es que la solicitud fue entendida, pero no voy a hacer lo que me piden (porque las cosas están mal). La entidad de respuesta explica qué está mal, por lo 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 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
público por qué la solicitud no se ha cumplido, DEBERÍA describir el motivo del rechazo en la entidad. Si el servidor no desea que esta información esté disponible para el cliente,
se puede utilizar el código de estado 404 (No encontrado).

cdeszaq
fuente
44
Suena bien inicialmente, aunque naturalmente lo asociaría con errores basados ​​en autenticación o permisos. Además, la especificación apunta a esto donde dice "si el servidor no desea que esta información esté disponible para el cliente". También ese 404 podría ser una mejor opción. Me dirigiría hacia un 404 o 400 que un 403.
tonyhb
21
Esta es una idea terrible, aunque sea técnicamente sólida. 403 se usa universalmente para respuestas de falla de autenticación, y confundirá a sus clientes si intenta usar esto para indicar errores de parámetros. Por ejemplo, Twitter hace esto: 403 se usa cuando proporciona credenciales de OAuth no válidas y cuando hay algo semánticamente incorrecto en su solicitud, y es una fuente constante de confusión para los clientes API.
Matt Zukowski el
1
@MattZukowski bueno, eso está mal. La especificación dice Authorization will not help, por lo que Twitter no debería enviar esto por credenciales de OAuth no válidas.
torvin
@torvin Twitter debería enviar un 401 Unauthorizeden su lugar. Sin embargo, puede entender por qué no lo hacen si mira las descripciones de los dos documentos de MDN de estos dos códigos, que son muy similares.
Agi Hammerthief
-1

Solo para usar ASP.NET Core como referencia o ejemplo, ASP.NET Core le permite construir un controlador con acciones, así es como se ve la acción "Detalles".

    // 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);
    }

Si el parámetro idno está configurado, devuelve 404 No encontrado.

Fred
fuente
-5

Devuelve un 404 , lo que significa que no se pudo encontrar el recurso.

Intente editar una url de un sitio que contenga una identificación. Probé algunos:

  • problema de repositorio de gitub
  • página de confluencia
  • vista del producto amazon
  • listado de eBay
  • artículo de noticias de bbc

Todos devuelven 404, en mi opinión, porque esos desarrolladores están interpretando el estándar correctamente, lo que la respuesta aquí y muchas otras no.

jenson-button-event
fuente
1
Creo que la mayoría de los desarrolladores definen "parámetro" como uno de los pares de nombre / valor en una cadena de consulta o en el cuerpo POST del formulario. Una solicitud de problema de repositorio de Github no contiene esto.
Kelvin
@Kelvin que los desarrolladores también incluyen parámetros de ruta en la lista. si CUALQUIER parámetro de URL es obligatorio, representa la ubicación de un recurso y no está incluido, entonces debe devolverse 404. Esto excluye el requestBody.
jenson-button-event
-6

Yo iría con un 403.

Desde 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 por qué la solicitud no se ha cumplido, DEBERÍA describir el motivo del rechazo en la entidad. Si el servidor no desea que esta información esté disponible para el cliente, se puede utilizar el código de estado 404 (No encontrado).

Debe describir la razón del fracaso en su respuesta. Si prefiere no hacerlo, simplemente use 404.

Francisco Costa
fuente
3
rechazado porque esta es una respuesta duplicada. Considere agregar su última oración como comentario a la respuesta anterior que ofrece usar 403
usuario del