Cuál es el código de respuesta HTTP adecuado para la solicitud sin campos obligatorios

Question

Considere el caso simple donde el usuario está eliminando una publicación. Esta es una solicitud HTTP DELETE/POST simple con un campo obligatorio, post_id.

¿Qué debe hacer el servidor si no se proporciona post_id?

Aparentemente, el usuario nunca debe encontrar este comportamiento, así que seamos puristas.

Mi primera toma 400 sería mala petición, pero especificación dice

The request could not be understood by the server due to malformed syntax. The client SHOULD NOT repeat the request without modifications. 

y me gustaría decir que falta el campo está bien de la sintaxis/http Punto de vista, es de aplicación el requisito semántica de dominio específico.

200 OK con explicaciones es malo, 500 se siente raro ya que este es un problema de solicitud.

¿Pensamientos?

Answer 1

400 es la respuesta correcta.

400 no está restringido a una sintaxis mal formada desde un punto de vista HTTP. Falta un argumento obligatorio un error en la sintaxis definida por la aplicación y por lo tanto una "solicitud incorrecta"

EDITAR

Al principio parece extraño que no existe un código de retorno separado para esto, pero la vuelta los códigos están diseñados para diferenciar en qué acciones debe tomar el cliente. Un código de error 400 significa que el cliente debe cambiar los datos POST o cadena de consulta al formato definido por la aplicación. Por lo tanto, es apropiado para este caso.

Answer 2

En un escenario REST, el recurso a eliminar debe identificarse por la URL, por lo que la ID del recurso debe ser parte de esa URL para poder identificarla correctamente. Una vez que esa suposición es correcta, la URL identifica un recurso diferente fr eliminación, o no (que daría un 404)

En el caso general de un parámetro faltante, sin embargo, a menudo uso un 403 Error prohibido 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í.

De rfc2616:

10.4.4 403 Forbidden

El servidor ha entendido la solicitud, pero se niega a cumplirlo.
La autorización no ayudará y la solicitud NO DEBE repetirse.
Si el método de solicitud no fue HEAD y el servidor desea hacer
público por qué la solicitud no se ha cumplido, DEBERÍA describir el motivo de la denegación 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) en su lugar.