2009-02-04 22 views
11

Diciamo che ho una risorsa che può avere due comportamenti diversi quando delete viene chiamatoRESTful strategia di eliminazione

  1. La risorsa viene eliminata.
  2. La risorsa viene spostata nel cestino.

Come si modellerebbe in un modo conforme a REST?

ho pensato alla seguente soluzione:

DELETE /myresource  

sposta la risorsa nel cestino (comportamento di default)

DELETE /myresource?force-delete=true 

forze cancellare sulla risorsa.

È conforme a REST? Non ho mai visto parametri di query nell'URL quando si chiama DELETE, ok?

risposta

4

Una strategia REST pura dovrebbe preferire risorse che non cambiano. Secondo me, non stai cambiando la risorsa aggiungendo un parametro, quindi mi sembra una buona strategia.

Se si dovesse eseguire la stessa azione in questo modo:

DELETE /myresource.force 

che avrebbe agito come un'altra risorsa, che non sarebbe ottimale.

+2

Questo rompe le "regole" di REST in quanto si sta indirizzando una risorsa diversa. Allo stesso tempo, anche /myresource.json e /myresource.xml forniscono diversi formati degli stessi dati (usa le intestazioni di accettazione, le persone!) Ma non sta andando via in qualunque momento presto. –

+0

Questo non è 'REST', stai facendo azioni in modo RPC. – thecoshman

2

Perché no? Stai già passando un parametro per identificare quale risorsa, quindi invia un altro per stabilire una diversa linea di condotta. IMO, è perfettamente riposante.

11

La tua idea va bene, ma penso che un'intestazione di richiesta personalizzata sarebbe un po 'più appropriata. I parametri di query sono più adatti a, beh, i parametri. intestazione di richiesta

Un'usanza sarebbe simile a questa:

DELETE /myresource 
X-Really-Delete: Yup 
2

Si potrebbe anche implementare 2. come una richiesta POST, invece di CANC.

POST /myresource 

recycle-bin=true... 

Come in tutto ciò che si sta facendo è l'aggiornamento della risorsa per indicare che è nel cestino.

EDIT: metodo cambiato da PUT a POST dato un PUT deve racchiudere una sostituzione completa (o aggiunta) della risorsa, mentre chiaramente qui stiamo aggiornando solo una parte della risorsa.

+0

Contro il tuo passaggio da PUT a POST. POST è per la creazione di contenuti, PUT è per le modifiche; tutto ciò che l'OP sta facendo è segnare una risorsa con un certo valore, cioè aggiornarla. – thecoshman

+0

@thecoshman PUT è creato o sostituito che richiede l'inclusione dell'intera entità nella richiesta. Le modifiche potrebbero essere apportate tramite il metodo PATCH ma con supporto limitato. – rojoca

+0

ehm ... un po '. PUT può essere usato per creare contenuti, così come il POST. La differenza sta nel PUT che si crea in un URI specifico, mentre il POST si sta chiedendo al server di capire quale URI lo memorizza come. PUT può anche essere usato per completare sostituire una risorsa. Hai ragione nel dire che PATCH è il metodo giusto per fare un aggiornamento minore come questo. In assenza di un supporto adeguato, la soluzione "corretta" sarebbe quella di OTTENERE la risorsa completa, aggiornarla e PUT della risorsa di aggiornamento completa sul server, allo stesso URI. – thecoshman

2

DELETE dovrebbe eliminare l'elemento, senza fare domande.

Purtroppo non è presente la richiesta "MOVE" in HTTP. Il POST di solito è inteso per la creazione di contenuti, PUT è più modifiche.

Quindi ti suggerisco di fare qualcosa come PUT /myresource con una qualche forma di meta-dati o una stringa json lungo le linee di { "recycle":"true" } per indicare che vuoi "riciclarlo".