2009-02-04 15 views
11

Digamos que tengo un recurso que puede tener dos comportamientos diferentes cuando se llama borradoestrategia de eliminación REST

  1. Se elimina el recurso.
  2. El recurso se mueve a la papelera de reciclaje.

¿Cómo se modelizaría de forma REST?

pensé en la siguiente solución:

DELETE /myresource  

mueve el recurso a la papelera de reciclaje (comportamiento predeterminado)

DELETE /myresource?force-delete=true 

fuerzas de borrar en el recurso.

¿Cumple con REST? Nunca he visto parámetros de consulta en la URL al llamar a DELETE, ¿está bien?

Respuesta

4

Una estrategia de REST pura debería preferir recursos que no cambian. En mi opinión, no está cambiando el recurso agregando un parámetro, por lo que me parece una buena estrategia.

Si se va a realizar la misma acción, así:

DELETE /myresource.force 

que actuaría como un recurso más, lo cual no sería óptimo.

+2

Esto rompe las 'reglas' de REST en el sentido de que se dirige a un recurso diferente. Al mismo tiempo, también lo hacen /myresource.json y /myresource.xml proporcionando diferentes formatos de la misma información (¡use sus encabezados de aceptación, personas!) Pero eso no va a desaparecer pronto. –

+0

Esto no es 'REST', estás haciendo acciones en una forma RPC. – thecoshman

2

¿Por qué no? Ya está pasando un parámetro para identificar qué recurso, así que envíe otro para establecer un curso de acción diferente. OMI, es perfectamente RESTful.

11

Su idea está bien, pero creo que un encabezado de solicitud personalizada sería un poco más apropiado. Los parámetros de consulta son más adecuados para, bueno, los parámetros. encabezado de solicitud

Una costumbre sería algo como esto:

DELETE /myresource 
X-Really-Delete: Yup 
2

También podría implementar 2. como una solicitud POST en lugar de BORRAR.

POST /myresource 

recycle-bin=true... 

Como todo lo que hace es actualizar el recurso para indicar que está en la papelera de reciclaje.

EDITAR: método cambió de PUT a POST dado un PUT deberán adjuntar un reemplazo completo (o además) del recurso, mientras que claramente aquí sólo estamos actualizando una parte del recurso.

+0

Discutiría en contra de su cambio de PUT a POST. POST es para crear contenido, PUT es para modificaciones; todo lo que OP está haciendo realmente es marcar un recurso con un cierto valor, es decir, actualizarlo. – thecoshman

+0

@thecoshman PUT es crear o reemplazar, lo que requiere que la entidad completa esté incluida en la solicitud. Las modificaciones se pueden hacer a través del método PATCH, pero eso tiene un soporte limitado. – rojoca

+0

erh ... algo. PUT se puede usar para crear contenido, como POST. La diferencia es que PUT creas en un URI específico, mientras que POST le pides al servidor que resuelva con qué URI almacenarlo. PUT también se puede usar para completar el reemplazo de un recurso. Tiene razón al decir que realmente PATCH es el método correcto para hacer una actualización menor como esta. En ausencia de un soporte adecuado, la solución 'adecuada' sería OBTENER el recurso completo, actualizarlo y PONER el recurso de actualización completo nuevamente en el servidor, en el mismo URI. – thecoshman

2

ELIMINAR debería eliminar el elemento, sin hacer preguntas.

Lamentablemente, no hay una solicitud 'MOVE' en HTTP. POST suele ser para crear contenido, PUT es más modificaciones.

Así que le sugiero que haga algo como PUT /myresource con alguna forma de metadatos o una cadena json en la línea de { "recycle":"true" } para indicar que quiere 'reciclarla'.