Stato HTTP 202: come fornire informazioni sul completamento della richiesta asincrona?

Qual è il modo appropriato di fornire una stima per il completamento della richiesta quando il server restituisce un codice di stato 202 - Accepted per richieste asincrone?Stato HTTP 202: come fornire informazioni sul completamento della richiesta asincrona?

Dalle HTTP spec (corsivo aggiunte da me):

202 accettate

La richiesta è stata accettata per l'elaborazione, ma l'elaborazione non è stata completata. [...]

L'entità ritornò con questa risposta dovrebbe includere un'indicazione dello stato attuale del richiesta e sia un puntatore a un monitor di stato o di qualche stima quando l'utente può aspettarsi la richiesta da soddisfare.

Ecco alcuni dei pensieri:

ho guardò la direttiva max-age, ma il suo utilizzo sarebbe abusando Cache-Control?
Restituisce il tempo di attesa previsto nel corpo della risposta?
Aggiungere un'intestazione di risposta X- specifica dell'applicazione, ma le intestazioni X- sono state dichiarate obsolete in RFC 6648?
Aggiungere un'intestazione di risposta specifica (non X-)? Se sì, come dovrebbe essere nominato? La domanda SO Custom HTTP headers : naming conventions ha dato alcune idee, ma dopo la deprecazione risponde solo al modo in cui sono formattate le intestazioni HTTP, non come dovrebbero essere nominati.
Altri suggerimenti?

fonte

2013-02-12 matsev

Sebbene non indicato esplicitamente per il codice di risposta 202 - Accepted, l'intestazione Retry-After sembra essere un'opzione adatta. A partire da documentation:

Il campo di intestazione Risposta post-tentativi può essere utilizzato [...] per indicare per quanto tempo il servizio non sarà disponibile per il client richiedente.

fonte

2013-03-27 09:51:01 matsev

Dato che il valore dovrebbe essere "numero intero di secondi (in decimale) ", se vogliamo una risoluzione migliore, l'intestazione' X-Retry-After' con valori in es i millisecondi saranno invece più appropriati? –

@JosipRodin Io suggerisco di usare 'Retry-After: 0' invece di inventare un'intestazione personalizzata perché nel momento in cui il client ottiene la risposta, alcuni millisecondi sarebbero passati comunque e possono riprovare subito. Nel caso di un'operazione asincrona, 'Retry-After: 0' sembra dire" il risultato non è ancora pronto, ma sentiti libero di chiedere di nuovo (ogni volta che lo desideri). " – Gili

@ Gili ma cosa succede se non voglio che chiedano quando vogliono? Ad esempio, se la maggior parte dei client si trova a 150ms di distanza, si tratta di 6 richieste al secondo, in cui potrei aver avuto l'idea di avere solo 2 richieste al secondo. –

Sicuramente non utilizzare le intestazioni HTTP esistenti per questo. Dato che è il tuo server, puoi definire come appare la risposta. È possibile (e dovrebbe) scegliere qualsiasi risposta che funzioni meglio per il destinatario previsto di queste informazioni e restituire le informazioni effettive nel corpo della risposta.

Ad esempio, se si è interessati solo alla visualizzazione di un messaggio leggibile dall'uomo, è possibile restituire text/plain dicendo "È probabile che la richiesta venga elaborata nei prossimi 30 minuti.".

All'altra estremità dello spettro, si potrebbe desiderare di andare fino in fondo REST e tornare application/json, forse formattato come questo (ho assolutamente fatto questo sul posto):

{ 
    "status": "pending", 
    "completion": { 
    "estimate": "Thu Sep 08 2011 12:00:00 GMT-0400", 
    "rejected-after": "Fri Sep 09 2011 12:00:00 GMT-0400", 
    }, 
    "tracking": { 
    "url": "http://server/status?id=myUniqueId" 
    } 
}

fonte

2013-02-12 13:29:51 Jon

È possibile utilizzare l'intestazione Location per specificare l'URL del monitor di stato. Cose come lo stato corrente e la stima possono andare in intestazioni personalizzate (che nessuno utilizzerà solo il proprio software) o nel corpo della risposta (che un browser Web visualizzerebbe a un utente, almeno).

fonte

2013-02-12 13:31:47

Grazie, ho dimenticato l'intestazione 'Location'. Molto probabilmente, useremo un corpo di risposta personalizzato. – matsev

Come accade, in realtà non si può usare l'intestazione 'Location' con un HTTP 202 in PHP, perché impone una semantica speciale per RFC 2616, cf. http://php.net/manual/en/function.header.php "Il secondo caso speciale è l'intestazione" Location: "Non solo restituisce questa intestazione al browser, ma restituisce anche un REDIRECT (302) codice di stato per il browser a meno che non sia già stato impostato il codice di stato 201 o 3xx. " –

@JosipRodin RFC 2616 non limita l'utilizzo di 'Location' in 202 (o qualsiasi altra risposta), ma definisce semplicemente che cosa si intende per" Location "in caso di 201/3xx. Quindi questa è una semantica di PHP (o bug, a seconda di come la si guarda), non una semantica HTTP. –

Stato HTTP 202: come fornire informazioni sul completamento della richiesta asincrona?

risposta

Problemi correlati