Ad esempio, se chiamo GET per ottenere un elemento, cancellarlo con DELETE e RICEVILO di nuovo, come dovrebbe funzionare il secondo GET?Come gestire i dati obsoleti in REST?
Intendo, seguendo correttamente i principi REST, qual è l'approccio corretto in questo poiché GET può essere memorizzato nella cache e tutto? Qual è l'approccio per gestire i dati obsoleti in REST?
Prima di tutto, il comportamento dipende da ciò che la chiamata DELETE ha restituito come codice di risposta.
Se DELETE restituisce 200 - OK o 204 - No Content, il client deve ricevere 404 - Not Found alla successiva chiamata a GET. Questo perché 202 e 204 significano che la risorsa è stata cancellata immediatamente.
Tuttavia, se DELETE restituisce 202 - Accepted, è possibile che il client sia in grado di ottenere correttamente la risorsa per qualche tempo dopo. Questo perché 202 indica che la risorsa è stata contrassegnata per l'eliminazione, ma non necessariamente ripulita immediatamente.
In secondo luogo, se è coinvolta una cache, il comportamento deve essere costruito per essere coerente con ciò che accadrebbe se non fosse presente la cache. Un DELETE riuscito dovrebbe sempre portare a una rimozione sia dalla vera origine dei dati che da eventuali copie memorizzate nella cache.
Come originariamente indicato, un GET che segue un DELETE dovrebbe produrre un errore HTTP 404 indipendentemente dalla cache che potrebbe essere presente. Il codice logico dovrebbe essere abbastanza intelligente da rimuovere il record dall'archivio permanente e dall'archivio o dalla cache in memoria. Inoltre, l'interfaccia utente dovrebbe essere in grado di gestire il risultato della 404 con qualsiasi flusso o processo che si ritenga appropriato.
Se hai appena cancellato l'elemento, perché dovresti provare a "riprenderlo" di nuovo? Non esisterà. Forse mi manca qualcosa o la domanda non era chiara. –
@Brent Pabst: prendi in considerazione ad esempio i collegamenti in un'applicazione di interfaccia utente in cui l'eliminazione avviene in un popup ma il collegamento GET si trova nella pagina di apertura e non viene aggiornato o trasferito per posta e l'utente li inserisce nella barra degli indirizzi del browser direttamente tra l'eliminazione ecc. Questo è soggetto alla cache! L'idea è, se l'elemento non è più lì, come dovrebbe funzionare il GET. Disabilita TUTTA la cache? È accettabile avere un po 'di cache? Qual è l'approccio REST a tutto questo? – JohnDoDo
Il secondo GET restituirebbe naturalmente il codice HTTP '404 Not Found'. Il caching è un'altra questione per la quale fornirò la risposta meravigliosamente opaca: "dipende". Ma se * è * un secondo GET, sembra piuttosto ovvio che produrrebbe un 404? –