standard restful actions http rest

http - actions - standard api restful



REST, HTTP DELETE y parámetros (4)

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


Mi situación es que estoy modelando el "¿Estás seguro de que deseas eliminar eso?" guión. En algunos casos, el estado del recurso sugiere que la eliminación solicitada puede no ser válida. Probablemente puedas imaginarte algunos escenarios donde 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 proceder con la eliminación ("? Force_delete = true")

p.ej

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

Creo que todavía está tranquilo ya que:

(a) La semántica de DELETE no se cambia: el usuario 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? Dado que HTTP es solo una implementación de REST, entonces, ¿por qué importar los parámetros de HTTP sería importante?


¿Puede alguien señalarme una declaración definitiva que aclare la razón por la cual esto no es RESTful?

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


Seguir

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

La primera es que la implementación posiblemente viola la "Interfaz uniforme" (ver la 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?

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

¿Tiene sentido especificar force_delete = true si esta fuera la API de un programa? Si alguien estaba escribiendo un script para eliminar este recurso, ¿podría obligarlos 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 los objetos dependientes también deben eliminarse. Este es un ejemplo de un parámetro DELETE que tiene sentido, pero ''man rm'' podría proporcionar otros. ¿Cómo se implementarían estos casos posiblemente 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 (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 de recursos, 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).

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/Conflict debe usar para situaciones donde hay un conflicto que impide que el servicio RESTful realice la operación, pero aún hay una posibilidad de que el usuario pueda resolver el conflicto él mismo. Una confirmación previa a la eliminación (donde no existen 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 votó negativamente, es correcto), esto debería manejarse en la interfaz de usuario, porque un servicio RESTful como tal solo procesa las solicitudes y, por lo tanto, debe ser apátrida (es decir, no debe confiar en las confirmaciones cualquier información del lado del servidor acerca de una solicitud).

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

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

(*) Tenga en cuenta que las versiones HTML anteriores a 5 no admiten PUT y BORRAR métodos HTTP de forma nativa, 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 más información sobre la compatibilidad con varios navegadores.

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

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

Entonces, 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).