REST, DELETE HTTP y parámetros

¿Hay algo que no sea RESTful sobre proporcionar parámetros a una solicitud HTTP DELETE?

Mi escenario es que estoy modelando el mensaje "¿Estás seguro de que quieres eliminar eso?" guión. En algunos casos, el estado del recurso sugiere que la eliminación solicitada puede no ser válida. Probablemente pueda imaginar algunos escenarios en los que se requiere la confirmación de una eliminación

La solución que hemos adoptado es pasar un parámetro a la solicitud de eliminación para indicar que está bien continuar con la eliminación ("? Force_delete = true")

p.ej

DELETE http://server/resource/id?force_delete=true

Creo que todavía es tranquilo ya que:

(a) La semántica de DELETE no se está cambiando: el usuario aún puede enviar una solicitud DELETE normal, pero esto puede fallar con 409 y el cuerpo de la respuesta explicará por qué. Digo que puede fallar porque (por razones que no vale la pena explicar) en algunas ocasiones no hay razón para avisar al usuario.

(b) No hay nada en la disertación de Roy que sugiera que está en contra del espíritu de REST: ¿por qué habría de existir ya que HTTP es solo una implementación de REST? ¿Por qué sería importante pasar los parámetros HTTP?

¿Alguien puede señalarme una declaración definitiva que explique la razón por la cual esto no es RESTful?

En una pregunta relacionada, si el usuario no especifica force_delete, entonces estoy regresando 409 Conflict: ¿es ese el código de respuesta más apropiado?

Seguimiento

Después de algunas investigaciones adicionales, creo que agregar parámetros a DELETE puede violar varios principios.

La primera es que la implementación posiblemente viola la "Interfaz Uniforme" (ver sección 5.1.5 de la disertación de Roy

Al agregar 'force_delete' estamos agregando una restricción adicional al método DELETE ya bien definido. Esta restricción es significativa solo para nosotros.

También podría argumentar que viola el "5.1.2 Cliente-Servidor" ya que el diálogo de confirmación es realmente una preocupación de UI y nuevamente no todos los clientes querrán confirmar la eliminación.

Sugerencias a alguien?

No, no es RESTful. La única razón por la que debería poner un verbo ( force_delete) en el URI es si necesita sobrecargar los métodos GET / POST en un entorno donde los métodos PUT / DELETE no están disponibles. A juzgar por su uso del método DELETE, este no es el caso.

El código de error HTTP 409/Conflictdebe usarse para situaciones en las que existe un conflicto que impide que el servicio RESTful realice la operación, pero aún existe la posibilidad de que el usuario pueda resolver el conflicto él mismo. Una confirmación previa a la eliminación (donde no hay conflictos reales que impidan la eliminación) no es un conflicto per se, ya que nada impide que la API realice la operación solicitada.

Como dijo Alex (no sé quién lo rechazó, él tiene razón), esto debe manejarse en la interfaz de usuario, porque un servicio RESTful como tal solo procesa solicitudes y, por lo tanto, no debe tener estado (es decir, no debe basarse en las confirmaciones manteniendo cualquier información del lado del servidor sobre una solicitud).

Dos ejemplos de cómo hacer esto en la interfaz de usuario serían:

• pre-HTML5 : * muestra un diálogo de confirmación JS al usuario y envía la solicitud solo si el usuario lo confirma
• HTML5 : * use un formulario con la acción ELIMINAR donde el formulario contendrá solo los botones "Confirmar" y "Cancelar" ("Confirmar" sería el botón de enviar)

(*) Tenga en cuenta que las versiones HTML anteriores a la 5 no son compatibles con los métodos HTTP PUT y DELETE, sin embargo, la mayoría de los navegadores modernos pueden hacer estos dos métodos a través de llamadas AJAX. Consulte este hilo para obtener detalles sobre la compatibilidad entre navegadores.

Actualización (basada en investigaciones y discusiones adicionales):

El escenario donde el servicio requeriría que la force_delete=truebandera esté presente viola la interfaz uniforme como se define en la disertación de Roy Fielding. Además, de acuerdo con HTTP RFC , el método DELETE puede anularse en el servidor de origen (cliente), lo que implica que esto no se hace en el servidor (servicio) de destino.

Por lo tanto, una vez que el servicio recibe una solicitud DELETE, debe procesarla sin necesidad de confirmación adicional (independientemente de si el servicio realmente realiza la operación).

Creo que esto no es tranquilo. No creo que el servicio reparador deba manejar el requisito de obligar al usuario a confirmar una eliminación. Me ocuparía de esto en la interfaz de usuario.

¿Tiene sentido especificar force_delete = true si esta fuera la API de un programa? Si alguien escribiera un script para eliminar este recurso, ¿desearía obligarlo a especificar force_delete = true para eliminar realmente el recurso?

Es una vieja pregunta, pero aquí hay algunos comentarios ...

1. En SQL, el comando DELETE acepta un parámetro "CASCADE", que le permite especificar que también se eliminen los objetos dependientes. Este es un ejemplo de un parámetro DELETE que tiene sentido, pero 'man rm' podría proporcionar otros. ¿Cómo se podrían implementar estos casos en REST / HTTP sin un parámetro?
2. @ Jan, parece ser una convención bien establecida que la parte de ruta de la URL identifica un recurso, mientras que la cadena de consulta no lo hace (al menos no necesariamente). Abundan los ejemplos: obtener el mismo recurso pero en un formato diferente, obtener campos específicos de un recurso, etc. Si consideramos la cadena de consulta como parte del identificador del recurso, es imposible tener un concepto de "diferentes vistas del mismo recurso" sin recurrir a mecanismos no RESTful como la negociación de contenido HTTP (que puede ser indeseable por muchas razones).

Además de la respuesta de Alex:

Tenga en cuenta que http: // server / resource / id? Force_delete = true identifica un recurso diferente que http: // server / resource / id . Por ejemplo, es una gran diferencia si elimina / clients /? Status = old o / clients /.

ene