[pugMI] Affidabilita' servizi REST/HTTP

[Giorgio Sironi]

Il 15/set/2014 11:04 "Davide Marrone" <davide a skebby.com> ha scritto:
>
> Ciao a tutti,
> ho letto questo articolo:
> http://www.infoq.com/articles/no-reliable-messaging
>
> non recentissimo ma che mi sembra molto interessante per quanto riguarda
lo scambio di messaggi in maniera affidabile su REST o in generale su HTTP,
in particolare la parte "Once, and Only Once".
>
> Mi chiedevo se qualcuno ha mai implementato dei meccanismi del genere per
lo sviluppo di un API o se avete mai utilizzato delle API di altri che vi
hanno chiesto espressamente che ogni richiesta sia univoca, ad esempio
passando un ID e che l'API puo' rispondere con un codice di errore di
"richiesta duplicata".
>
> Per poter avere questo livello di affidabilita' il client che usa il
servizio remoto deve essere per forza coinvolto, deve sapere che:
>
> 1) ogni richiesta deve essere univoca o deve avere un ID
> 2) se non riceve una risposta puo' (e deve) ripetere la richiesta e puo'
stare tranquillo che non sara' processata due volte, es in caso di
creazione ordini o operazioni che hanno a che fare con il billing
> 3) come risposta puo' ricevere un messaggio di codice di "richiesta
duplicata" e lo deve gestire
>
> @onebip: voi avete qualcosa del genere sulle API che date i clienti che
possono billare un numero? Come fa il client a sapere se la sua richiesta
e' stata processata, la connessione potrebbe saltare prima che ricevere il
200 o il messaggio di risposta.

Torna tutto:
- se salta prima di iniziare, il client ripete la richiesta con lo stesso
id senza problemi
- se salta dopo che lo stato é cambiato, il client ripete la richiesta
identica ma riceve 409 Conflict anziché 200 e smette di riprovare
- se il server crasha a metà, il server deve garantire che la richiesta é
gestita in modo idempotente

Il problema sorge se devi chiamare un'api esterna non idempotente, qui
sorgono considerazioni di business (meglio at least once o at most once?)

>
> Ciao
> Davide
> _______________________________________________
> Milano mailing list
> Milano a ml.grusp.org
> http://ml.grusp.org/listinfo.cgi/milano-grusp.org
-------------- parte successiva --------------
Un allegato HTML è stato rimosso...
URL: <http://ml.grusp.org/pipermail/milano-grusp.org/attachments/20140915/544c8f8d/attachment.htm>