REST, DELETE HTTP e parametri

Esiste qualcosa di non RESTful nel fornire parametri a una richiesta DELETE HTTP?

Il mio scenario è che sto modellando "Sei sicuro di volerlo eliminare?" scenario. In alcuni casi, lo stato della risorsa suggerisce che l'eliminazione richiesta potrebbe non essere valida. Probabilmente puoi immaginare alcuni scenari in cui è richiesta la conferma di un'eliminazione

La soluzione che abbiamo adottato è di passare un parametro alla richiesta di eliminazione per indicare che è possibile procedere con l'eliminazione ("? Force_delete = true")

per esempio

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

Credo che sia ancora riposante poiché:

(a) La semantica di DELETE non viene modificata: l'utente può comunque inviare una normale richiesta DELETE, ma ciò potrebbe non riuscire con 409 e il corpo della risposta spiegherà il perché. Dico che potrebbe non funzionare perché (per motivi che non valgono la pena spiegare) in alcune occasioni non vi è alcun motivo per sollecitare l'utente.

(b) Non c'è nulla nella tesi di Roy che suggerisca che è contro lo spirito di REST - perché dovrebbe esserci poiché HTTP è solo un'implementazione di REST, quindi perché il passaggio dei parametri HTTP è importante

Qualcuno può indicarmi un'affermazione definitiva che inchioda il motivo per cui questo non è RESTful?

Su una domanda correlata, se l'utente non specifica force_delete, allora torno 409 Conflict- è il codice di risposta più appropriato?

Azione supplementare

Dopo alcune ulteriori ricerche, penso che l'aggiunta di parametri a DELETE possa violare diversi principi.

Il primo è che l'implementazione potrebbe violare la "Uniform Interface" (vedere la sezione 5.1.5 della tesi di Roy

Aggiungendo 'force_delete' stiamo aggiungendo un ulteriore vincolo al metodo DELETE già ben definito. Questo vincolo è significativo solo per noi.

Si potrebbe anche sostenere che viola il "5.1.2 Client-Server" poiché il dialogo di conferma è in realtà un problema di interfaccia utente e, di nuovo, non tutti i client vorranno confermare l'eliminazione.

Suggerimenti qualcuno?

No, non è RESTful. L'unico motivo per cui dovresti inserire un verbo ( force_delete) nell'URI è se dovresti sovraccaricare i metodi GET / POST in un ambiente in cui i metodi PUT / DELETE non sono disponibili. A giudicare dall'uso del metodo DELETE, non è così.

409/ConflictÈ necessario utilizzare il codice di errore HTTP per le situazioni in cui esiste un conflitto che impedisce al servizio RESTful di eseguire l'operazione, ma esiste ancora la possibilità che l'utente sia in grado di risolvere il conflitto da solo. Una conferma di pre-cancellazione (dove non ci sono conflitti reali che impedirebbero la cancellazione) non è un conflitto di per sé, poiché nulla impedisce all'API di eseguire l'operazione richiesta.

Come ha detto Alex (non so chi lo abbia votato a fondo, ha ragione), questo dovrebbe essere gestito nell'interfaccia utente, perché un servizio RESTful come tale elabora solo le richieste e dovrebbe quindi essere apolide (cioè non deve fare affidamento sulle conferme tenendo premuto qualsiasi informazione sul lato server relativa a una richiesta).

Due esempi su come eseguire questa operazione nell'interfaccia utente sarebbero:

• pre-HTML5 : * mostra una finestra di dialogo di conferma JS all'utente e invia la richiesta solo se l'utente la conferma
• HTML5 : * utilizza un modulo con azione ELIMINA in cui il modulo conterrebbe solo i pulsanti "Conferma" e "Annulla" ("Conferma" sarebbe il pulsante di invio)

(*) Le versioni HTML precedenti alla 5 non supportano i metodi PUT e DELETE HTTP in modo nativo, tuttavia la maggior parte dei browser moderni può eseguire questi due metodi tramite chiamate AJAX. Vedi questa discussione per i dettagli sul supporto cross-browser.

Aggiornamento (basato su ulteriori indagini e discussioni):

Lo scenario in cui il servizio richiederebbe la presenza della force_delete=truebandiera viola l' interfaccia uniforme come definito nella tesi di Roy Fielding. Inoltre, come per HTTP RFC , il metodo DELETE può essere ignorato sul server di origine (client), il che implica che ciò non viene eseguito sul server di destinazione (servizio).

Pertanto, una volta che il servizio riceve una richiesta DELETE, dovrebbe elaborarla senza richiedere ulteriori conferme (indipendentemente dal fatto che il servizio esegua effettivamente l'operazione).

Penso che questo non sia riposante. Non credo che il servizio riposante dovrebbe gestire il requisito di forzare l'utente a confermare l'eliminazione. Lo gestirò nell'interfaccia utente.

Specificare force_delete = true ha senso se si trattasse dell'API di un programma? Se qualcuno stesse scrivendo uno script per eliminare questa risorsa, vorresti forzarlo a specificare force_delete = true per eliminare effettivamente la risorsa?

È una vecchia domanda, ma ecco alcuni commenti ...

1. In SQL, il comando DELETE accetta un parametro "CASCADE", che consente di specificare che anche gli oggetti dipendenti devono essere eliminati. Questo è un esempio di un parametro DELETE che ha senso, ma "man rm" potrebbe fornire altri. Come potrebbero essere implementati questi casi in REST / HTTP senza un parametro?
2. @Jan, sembra essere una convenzione consolidata che la parte del percorso dell'URL identifichi una risorsa, mentre la querystring non lo fa (almeno non necessariamente). Gli esempi abbondano: ottenere la stessa risorsa ma in un formato diverso, ottenere campi specifici di una risorsa, ecc. Se consideriamo la stringa di query come parte dell'identificatore di risorsa, è impossibile avere un concetto di "viste diverse della stessa risorsa" senza ricorrere a meccanismi non RESTful come la negoziazione del contenuto HTTP (che può essere indesiderabile per molte ragioni).

Oltre alla risposta di Alex:

Si noti che http: // server / risorsa / id? Force_delete = true identifica una risorsa diversa da http: // server / risorsa / id . Ad esempio, è una grande differenza se si cancella / customers /? Status = old o / customers /.

Jan