pagina - ¿Qué código de estado HTTP usar para los parámetros requeridos no provistos?
status code 200 (5)
¿Qué código de estado debo devolver si se llamó a una de estas páginas sin los parámetros necesarios? (y por lo tanto no puede devolver ningún contenido).
Podría elegir 404 Not Found :
El servidor no ha encontrado nada que coincida con el URI de solicitud [suponiendo que los parámetros necesarios son parte del URI, es decir
$_GET] . No se indica si la condición es temporal o permanente. El código de estado 410 (Gone) DEBERÍA ser utilizado si el servidor sabe, a través de algún mecanismo configurable internamente, que un recurso antiguo está permanentemente no disponible y no tiene dirección de reenvío. Este código de estado se usa comúnmente cuando el servidor no desea revelar exactamente por qué se rechazó la solicitud o cuando no se aplica ninguna otra respuesta.
(resaltar por mí)
404 Not Found es un subconjunto de 400 Bad Request que podría tomarse también porque es muy claro acerca de qué es esto:
La solicitud no pudo ser entendida por el servidor debido a una sintaxis mal formada. El cliente NO DEBE repetir la solicitud sin modificaciones.
En realidad, no puedo sugerirle que elija un código de respuesta WEBDAV que no existe para los clientes HTTP que usan hipertexto, pero podría, es totalmente válido, usted es el codificador del servidor, puede tomar cualquier código de estado de resonse HTTP que considere oportuno para su cliente HTTP del cual usted es el diseñador también:
11.2. 422 Entidad no procesable
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 sintaxis 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.
La entidad de solicitud de IIRC es el cuerpo de solicitud. Entonces, si estás operando con cuerpos de solicitud, podría ser apropiado como escribió Julian.
Usted comentó:
En mi humilde opinión, el texto para 400 habla de sintaxis mal formada. Supongo que la sintaxis aquí se relaciona con la sintaxis de la cadena HTTP que el cliente envía al servidor.
Eso podría ser, pero puede ser cualquier cosa expresada sintácticamente, toda la solicitud, solo algunos encabezados de solicitud, o un encabezado de solicitud específico, el URI de solicitud, etc. 400 No es específicamente sobre "sintaxis de cadena HTTP", de hecho es la respuesta general a un error del cliente:
El código de estado de la clase 4xx está destinado a los casos en los que el cliente parece haber cometido un error. Excepto cuando se responde a una solicitud HEAD, el servidor DEBERÍA incluir una entidad que contenga una explicación de la situación de error, y si se trata de una condición temporal o permanente. Estos códigos de estado son aplicables a cualquier método de solicitud. Los agentes de usuario DEBERÍAN mostrar cualquier entidad incluida al usuario.
La parte importante es que debe decirle al cliente qué fue lo que salió mal. El código de estado solo indica que algo salió mal (en la clase 4xx), pero HTTP no se ha diseñado específicamente para hacer que un parámetro de parte consulta-información faltable como una condición de error. De hecho, URI solo sabe que hay una parte consulta-info y no lo que significa.
Si crees que 400 es demasiado amplio, te sugiero que elijas 404 si el problema está relacionado con el URI, por ejemplo, las variables $_GET .
Tengo varias páginas diseñadas para ser llamadas con AJAX: les pido que devuelvan un código de estado anormal si no se pueden mostrar, y mi javascript mostrará un cuadro de error en consecuencia.
Por ejemplo, si el usuario no está autenticado o su sesión ha expirado y tratan de llamar a una de las páginas de AJAX, devolverá 401 Unathorized .
También tengo algún retorno 500 Internal Server Error si algo realmente extraño sucede en el servidor.
¿Qué código de estado debo devolver si se llamó a una de estas páginas sin los parámetros necesarios? (y por lo tanto no puede devolver ningún contenido).
Eché un vistazo al artículo de Wikipedia sobre códigos de estado HTTP , pero el más cercano que encontré al código que busco fue este:
422 Entidad no procesable
La solicitud estaba bien formada, pero no se pudo seguir debido a errores semánticos.
Editar: El código anterior es específico de WebDAV y, por lo tanto, es improbable que sea apropiado en este caso
¿Alguien puede pensar en un código apropiado para regresar?
422 es un código de estado HTTP regular; y se usa fuera de WebDAV. Al contrario de lo que otros dicen, no hay problema con eso; HTTP tiene un registro de código de estado por una razón.
Descripción como se cita contra 400
La solicitud no pudo ser entendida por el servidor debido a una sintaxis mal formada . El cliente NO DEBE repetir la solicitud sin modificaciones.
(Énfasis mío)
Eso habla de sintaxis mal formada, que no es el caso cuando el navegador envía una solicitud al servidor. Es solo el caso de los parámetros faltantes (mientras que no hay sintaxis mal formada).
Sugeriría que te quedes con 404 :)
(Los expertos me corrigen si estoy equivocado en cualquier lugar :))
Lea esto con cuidado:
https://en.wikipedia.org/wiki/List_of_HTTP_status_codes
422 es algo específico de WebDAV, y no lo he visto usado para nada más.
400, aunque no está destinado a este propósito particular, parece ser una opción común.
404 también es una opción viable si su API es RESTful o similar (utilizando la parte de ruta del URI para indicar los parámetros de búsqueda)
No sé sobre las intenciones de los escritores de RFC, pero el código de estado que he visto usado en la naturaleza para ese caso es 400 Bad Request .