REST e cache URI

Question

Come ho capito, utilizzando un servizio Web RESTful hypertext-driven, un client non dovrebbe conoscere nulla sul layout URI del server tranne per un paio di punti di ingresso noti. Questo dovrebbe consentire al server di controllare il proprio spazio URI e ridurre l'accoppiamento con il client.

Quando un client per il servizio invia una richiesta corretta per creare una nuova risorsa, il servizio risponde 201 CREATO e fornisce l'URI a cui è possibile accedere alla nuova risorsa nel campo dell'intestazione della posizione.

Un client può memorizzare questo URI per consentire l'accesso diretto alla risorsa in futuro e, in caso affermativo, per quanto tempo? Se gli URI sono memorizzati nella cache dal client, sembra che si stia configurando una situazione in cui ogni volta che il server cambia il proprio layout URI, sarà necessario assicurarsi che un reindirizzamento permanente venga pubblicato quando si accede ai vecchi URI. Altrimenti il ​​cliente si rompe. Nel corso di diversi anni, questo sistema di reindirizzamenti potrebbe sfuggire di mano.

Questa situazione non sembra aver dato al server molto più controllo sul suo spazio URI rispetto a un approccio ibrido REST-RPC che utilizza modelli URI.

Sono disponibili molte informazioni sulle rappresentazioni di memorizzazione nella cache, ma per quanto riguarda la memorizzazione nella cache degli URI nei sistemi RESTful basati su ipertesti?

Answer 1

Ricordare come Tim Berners-Lee ha detto, "URL interessanti non cambiano". Una volta che il server distribuisce un URI al client, è ora compito del server mantenere l'URI in uso in futuro (per esempio) inviando una risposta permanente spostata nel caso in cui l'URI sia cambiato e qualcuno richieda quello vecchio.

Questo è in realtà ciò che incoraggia molti a progettare URI opachi, come basati su ID di database o timestamp, piuttosto che utilizzare una proprietà leggibile dall'uomo della risorsa nell'URI. Qualunque cosa le persone capiscano, vorranno cambiare.

Answer 2

Poiché uno dei principali di REST è che le risorse sono indirizzabili, sembra perfettamente accettabile che un client tenga traccia dell'indirizzo (URI) per una determinata risorsa. Gli URI delle risorse dovrebbero essere uno dei "punti di ingresso ben noti" a cui si è fatto riferimento.

Answer 3

Sì, il client deve essere autorizzato a memorizzare l'URI. Per tutto il tempo che vuole. Come ha detto Licky, un cliente intelligente può utilizzare una risposta Moved-Permanently per aggiornare i suoi segnalibri.

Se ci pensate, abbiamo la migliore situazione possibile. Puoi cambiare gli URL sul server, mentre scegli di continuare a supportare i vecchi client per tutto il tempo che scegliamo, e i client intelligenti possono auto-aggiornarsi in modo efficace ai nuovi URL.

Per quanto tempo si decide di continuare a supportare questi vecchi URL, è davvero una decisione che deve essere presa in base ai client esistenti e alla facilità con cui possono essere gestiti.

Per me questo è un enorme miglioramento rispetto ai problemi di controllo delle versioni con interfacce in stile RPC.

Answer 4

So che questa è una domanda vecchia, ma penso che ci sia un sottocomponente alle risposte che vedo qui che non sono state affrontate.

Ricordare che non si sta recuperando la risorsa dal server, ma si sta recuperando una RAPPRESENTAZIONE di una risorsa. La risorsa stessa può avere la sua modifica identificativa primaria, o essere reinserita, o qualsiasi altra cosa, ma la rappresentazione che è stata restituita al client sulla creazione della risorsa può (o potrebbe non essere) valida indipendentemente; è tutta una questione di situazione.

Ad esempio, prendere in considerazione un sistema di caricamento contenuto moderato; un utente può avere la possibilità di caricare i contenuti a titolo oneroso da parte dei moderatori che potrebbero eventualmente far sì che il contenuto sia esposto a un pubblico/mercato più ampio. Al caricamento iniziale, il server può rispondere con un URI che indirizza (per esempio) "utenti/{userid}/upload/{contentid}" per quella rappresentazione di quel contenuto. Ad un certo punto, i moderatori possono decidere di promuovere il contenuto in una "prima pagina"; tale rappresentazione del contenuto può quindi essere disponibile all'URI di "content/{contentid}"; che non dovrebbe impedire all'uploader originale di accedere ai propri dati su "utenti/{userid}/upload/{contentid}"; nulla dice che ci debba essere un reindirizzamento permanente, e in effetti, c'è una buona ragione per cui non ci deve essere; se l'utente decide di voler rimuovere il contenuto, dovrebbe essere in grado di eseguire un DELETE sul contenuto; è probabilmente preferibile che gli utenti eseguano DELETE nelle rappresentazioni dei contenuti dalle proprie posizioni "caricate". Tuttavia, se i termini del sito indicano che i diritti degli utenti ai contenuti caricati sono revocati (non è raro), potrebbe avere senso che il processo di promozione della moderazione rimuova efficacemente il contenuto dall'area dell'utente, causando una "mossa permanente".

In realtà dipende interamente dalla situazione specifica; la validità di un URI memorizzato nella cache dipende completamente dalle politiche del server. Come minimo, penserei che una richiesta a un URI non valido (che potrebbe essere stato precedentemente valido) dovrebbe causare una risposta (coerente con HATEOAS) che può consentire al client di "riscoprire" la risorsa (rappresentazione) che stavano cercando ; per lo meno, un link al punto di ingresso.