Alternative RESTful per ELIMINARE l'ente di richiesta

Question

Mentre il consente di inviare corpi di messaggi sulle richieste DELETE, sembra indicare che i server devono ignorarlo poiché non esiste una semantica definita per esso.

4,3 Corpo del messaggio

un server dovrebbe leggere e inoltrare un messaggio-corpo su qualsiasi richiesta; se il metodo di richiesta non include la semantica definita per un corpo dell'entità, , il corpo del messaggio DOVREBBE essere ignorato durante la gestione della richiesta.

Ho già recensito diverse discussioni correlate su questo argomento su SO e al di là, come ad esempio:

• Is an entity body allowed for an HTTP DELETE request?
• Payloads of HTTP Request Methods
• HTTP GET with request body

maggior parte delle discussioni sembrano concordo che fornire un corpo del messaggio su DELETE può essere consentito, ma in genere non è raccomandato.

Inoltre, ho notato una tendenza in varie librerie client HTTP in cui sembra che vengano sempre più registrati miglioramenti per queste librerie per supportare i corpi delle richieste su DELETE. La maggior parte delle biblioteche sembra obbligare, anche se occasionalmente con un po 'di resistenza iniziale.

Il mio caso d'uso richiede l'aggiunta di alcuni metadati richiesti su un DELETE (ad esempio il "motivo" per l'eliminazione, insieme ad altri metadati richiesti per l'eliminazione). Ho considerato le seguenti opzioni, nessuna delle quali sembrano completamente adeguato e in linea con le specifiche HTTP e/o di riposo le migliori pratiche:

• corpo del messaggio - La specifica indica che il corpo dei messaggi su DELETE non hanno alcun valore semantico; non completamente supportato dai client HTTP; non pratica standard
• Intestazioni HTTP personalizzate - La richiesta di intestazioni personalizzate è generalmente against standard practices; utilizzarli è incoerente con il resto della mia API, nessuno dei quali richiede intestazioni personalizzate; inoltre, nessuna buona risposta HTTP a disposizione per indicare i valori di intestazione male personalizzati (probabilmente una questione a parte tutto)
• standard HTTP intestazioni - Nessuna testata standard sono appropriati
• parametri di query - Aggiunta di query params in realtà cambia la richiesta- URI cancellato; against standard practices
• Metodo POST - (ad esempio POST /resourceToDelete { deletemetadata }) Il POST non è un'opzione semantica per l'eliminazione; POST rappresenta in realtà il opposta azione desiderata (ad esempio POST crea subordinati di risorse, ma ho bisogno di eliminare la risorsa)
• multipli Metodi - Splitting la richiesta di eliminazione in due operazioni (ad esempio PUT eliminare i metadati, quindi eliminare) Split un operazione atomica in due, potenzialmente lasciando uno stato incoerente.Il motivo di eliminazione (e altri metadati correlati) non fanno parte della rappresentazione della risorsa stessa.

La mia prima preferenza sarebbe probabilmente quella di utilizzare il corpo del messaggio, in secondo luogo alle intestazioni HTTP personalizzate; tuttavia, come indicato, ci sono alcuni aspetti negativi di questi approcci.

Esistono raccomandazioni o best practice in linea con gli standard REST/HTTP per includere tali metadati richiesti sulle richieste DELETE? Ci sono altre alternative che non ho considerato?

Answer 1

Nonostante alcune raccomandazioni di non utilizzare il corpo del messaggio per le richieste DELETE, questo approccio potrebbe essere appropriato in alcuni casi d'uso. Questo è l'approccio che abbiamo utilizzato dopo aver valutato le altre opzioni menzionate nella domanda/risposte e dopo aver collaborato con i consumatori del servizio.

Mentre l'uso del corpo del messaggio non è l'ideale, nessuna delle altre opzioni si adattava perfettamente. Il corpo della richiesta DELETE ci ha permesso di aggiungere facilmente e con chiarezza semantica ai dati/metadati aggiuntivi necessari per accompagnare l'operazione DELETE.

Sarei ancora aperto ad altri pensieri e discussioni, ma volevo chiudere il ciclo su questa domanda. Apprezzo i pensieri e le discussioni di tutti su questo argomento!

Answer 2

Data la situazione che hai, vorrei prendere uno dei seguenti approcci:

• Invia un PUT o PATCH: sto deducendo che l'operazione di eliminazione è virtuale, per la natura del bisogno di una eliminazione ragionare. Pertanto, ritengo che l'aggiornamento del record tramite un'operazione PUT/PATCH sia un approccio valido, anche se non è un'operazione DELETE di per sé.
• Utilizzare i parametri di query: L'uri della risorsa non viene modificato. In realtà penso che questo sia anche un approccio valido. La domanda che hai collegato stava parlando di non consentire l'eliminazione se il parametro della query mancava. Nel tuo caso, avrei solo un motivo predefinito se il motivo non è specificato nella stringa di query. La risorsa sarà comunque resource/:id. Puoi renderlo rilevabile con le intestazioni di collegamento sulla risorsa per ciascun motivo (con un tag rel su ciascuna per identificare il motivo).
• Utilizzare un endpoint separato per motivo: Utilizzo di un url come resource/:id/canceled. Questo in realtà cambia l'URI della richiesta e non è sicuramente RESTful. Ancora una volta, le intestazioni dei collegamenti possono renderlo rilevabile.

Ricordare che REST non è legge o dogma. Pensalo più come guida. Quindi, quando ha senso non seguire la guida per il dominio del problema, non farlo. Assicurati solo che i tuoi utenti API siano informati della varianza.

Answer 3

Suggerisco di includere i metadati richiesti come parte della stessa gerarchia URI. Un esempio (Naive):

Se è necessario eliminare le voci in base a un intervallo di date, anziché passare la data di inizio e la data di fine nel corpo o come parametri di query, strutturare l'URI in modo tale da passare le informazioni richieste come parte dell'URI.

ad es.

DELETE /entries/range/01012012/31122012 - Eliminare tutte le voci comprese tra 01 gennaio 2012 al 31 dicembre 2012

Spero che questo aiuti.

Answer 4

Cosa ti sembra di volere è una delle due cose, nessuna delle quali sono una pura DELETE:

1. Hai due operazioni, un PUT della ragione di eliminazione seguita da una DELETE della risorsa. Una volta cancellati, i contenuti della risorsa non sono più accessibili a nessuno. La 'ragione' non può contenere un collegamento ipertestuale alla risorsa eliminata. Oppure,
2. Si sta tentando di modificare una risorsa da state=active a state=deleted utilizzando il metodo DELETE.Le risorse con stato = eliminato vengono ignorate dalla tua API principale ma potrebbero comunque essere leggibili da un amministratore o da qualcuno con accesso al database. Questo è permesso - DELETE non deve cancellare i dati di supporto per una risorsa, solo per rimuovere la risorsa esposta a quell'URI.

Qualsiasi operazione che richiede un corpo del messaggio su una richiesta DELETE può essere suddiviso in esso è la cosa più generale, un POST per fare tutti i compiti necessari con il corpo del messaggio, e un DELETE. Non vedo alcun motivo per rompere la semantica di HTTP.