Quindi, il meccanismo descritto in (informativo) RFC 7089 definisce un'estensione del meccanismo di negoziazione del contenuto definito nella specifica HTTP 1.1. I parametri di negoziazione del contenuto ufficialmente supportati oggi sono:
- Accetta
- Accept-Charset
- Accept-Language
- User-Agent
Queste intestazioni vengono utilizzate per informare il server del desiderio di una particolare versione di una risorsa (ad esempio Accept-Language: de). La specifica HTTP 1.1 definisce ciò che il server può fare in risposta a un tentativo di richiedere un tipo di contenuto che non supporta. In questo caso, il server dovrebbe rispondere con una risposta 406 (Non accettabile). Secondo le specifiche, la risposta 406 indica:
The resource identified by the request is only capable of generating
response entities which have content characteristics not acceptable
according to the accept headers sent in the request.
Che è coerente con un utente che specifica che desidera una particolare versione point-in-time di una risorsa ma quella versione non esiste.
Quindi, per la tua prima domanda (query per data prima della data iniziale), dovresti rispondere con un 406.
Per la tua seconda domanda (cosa fare sulle risorse non versionate) hai due scelte riguardo al significato dello stato della tua risorsa al momento richiesto.
Se consideri che le informazioni non basate sulla versione non hanno dimensione temporale, puoi decidere se riesce sempre o se fallisce sempre (sempre con un 406).
Affermare che "riesce sempre" è possibile affermare che i dati non versione siano validi per tutto il tempo (se non è versionato, non cambia mai) l'ipotesi definita dal sistema è che se i dati sono mai esistiti, allora sempre esisteva fin dall'inizio del tuo universo di sistema. Ad esempio, una richiesta di proprietà immutabile come UUID o numero seriale dovrebbe (eventualmente) avere sempre esito positivo.
Affermando che "fallisce sempre con 406" si potrebbe affermare che se l'utente ha specificato una data specifica si aspetta una versione delle informazioni e poiché la risorsa richiesta non ha versioni, il server non può soddisfare la richiesta e quindi dovrebbe generare una risposta all'errore.
Vorrei sostenere l'approccio sempre fallito.
Un paio di cose da notare:
-
RFC 7089 è informativo e non è garantito che diventi parte delle specifiche formali.
-
Dovresti prendere in considerazione l'aggiunta di un'intestazione Vary nella tua risposta per assicurarti che la cache faccia la cosa giusta con le risposte alle query con limiti di tempo.
-
È possibile ottenere lo stesso comportamento senza fare affidamento su RFC 7089 operando nei limiti delle attuali specifiche HTTP e utilizzando il meccanismo di accettazione generico con un intervallo di supporti personalizzato. Questo sarebbe roba personalizzata (di solito non è una buona cosa), ma RFC 7089 non è ufficiale.