Cosa fare quando la richiesta viene inviata al server e durante l'attesa di risposta alla connettività Internet persa?

Questo è un problema abbastanza comune con le transazioni asincrone e cade in più parti.

1. In che modo entrambe le parti sanno che la richiesta di transazione è stata ricevuta con successo?
2. Come rispedisci una richiesta di transazione che il cliente ritiene non sia stata ricevuta correttamente?
3. In che modo il server rileva le richieste di ripetizione dal client quando il server ha ricevuto la prima richiesta?
4. Come fa il cliente a sapere da dove ottenere i risultati della transazione?

Il bello di HTTP è che è abbastanza facile risolvere tutti questi problemi.

Immagina una struttura di URL come questa:

POST http://my.server.com/application/engine/queue
GET  http://my.server.com/application/engine/results?jobid=43425

Usare il post HTTP per inviare una richiesta al server, usando un ID di richiesta client univoco - e chiedere al server di rispondere con l'ID del lavoro. Dal punto di vista dei clienti, se questa risposta non si verifica, la richiesta deve essere inviata nuovamente. Dal punto di vista dei server, è necessario memorizzare nella cache la richiesta dell'ID del client per alcuni minuti, nel caso in cui il client invii richieste duplicate. Le richieste duplicate vengono gestite semplicemente restituendo lo stesso ID lavoro al client.

Il cliente ottiene i risultati della richiesta dall'URL dei risultati. Questa chiamata può essere ripetuta tutte le volte che è necessario per ottenere i risultati. Se è chiamato prima che i risultati siano disponibili, la risposta potrebbe essere una risposta NO-CONTENT in modo che il client sappia che il server riconosce l'id del lavoro ma non ha ancora il contenuto. Se l'ID del lavoro non viene riconosciuto, NOT-FOUND è la risposta appropriata.

Il risultato finale è che il client può sempre compiere un'azione sensata quando la rete viene persa e ripristinata e allo stesso modo il server può sempre elaborare le richieste dal client in modo ragionevole

Questo rientra nelle basi della comunicazione del protocollo. Una transazione è stata richiesta dal client Android e il server deve eseguire la transazione. Se la transazione dipende dalla conferma del client Android, si tratta di una chiamata di comunicazione ACK / NAK.

ACK (riconoscimento) e NAK (riconoscimento negativo) vengono utilizzati per indicare l'altro lato il risultato di una richiesta.

Quello che stai chiedendo è un tipo di scambio handshake tra il client e il server, e può essere eseguito con uno scambio di base ACK / NAK.

Ecco un esempio di Android che carica un file con riconoscimento a due vie.

Android -> upload files -> Server
Android <- ACK #id <- Server
Android -> ACK #id -> Server

Nell'esempio precedente ho aggiunto un identificatore univoco #id per la transazione. Il server dovrebbe ricevere i file, creare un record di transazione e inviarlo come risposta ad Android. Android dovrebbe quindi seguire con un riconoscimento di quella transazione (o in alternativa un NAK per un rifiuto).

Ecco un esempio di disconnessione di Android durante l'handshake.

Android -> upload files -> Server
Android <- ACK #id <- Server
/** no ACK response **/

Nell'esempio precedente il server ha accettato i file caricati e inviato una risposta di #id ACK su Android, ma Android non risponde mai con un ACK. Il dispositivo Android non è riuscito a completare l'handshake. Spetta a te decidere come il Server dovrebbe gestirlo. Distruggi la transazione, mantieni la transazione e attendi che il dispositivo Android torni più tardi o completi la transazione comunque.

Il server può presumere che dal momento che il dispositivo non ha risposto con ACK. Che il dispositivo Android non ha aggiornato lo stato interno per indicare che il caricamento è andato a buon fine. Scarterei la transazione e consentirò al dispositivo di ripeterlo in futuro.