[pugMI] Affidabilita' servizi REST/HTTP

Giorgio Sironi info a giorgiosironi.com
Mar 16 Set 2014 09:37:47 PDT


Il 16/set/2014 13:03 "Matteo Vaccari" <vaccari a pobox.com> ha scritto:
>
>
>
> 2014-09-16 10:37 GMT+02:00 Davide Marrone <davide a skebby.com>:
>>
>> On 15/09/14 18:25, Badkill wrote:
>>>
>>> Il giorno 15 settembre 2014 11:20, Davide Marrone <davide a skebby.com
>>> <mailto:davide a skebby.com>> ha scritto:
>>>
>>>
>>>
>>>     @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.
>>>
>>>
>>> Le 'risposte' avvengono solitamente in maniera asincrona, tramite delle
>>> notifiche che hanno un id univoco e posso essere 'ritentate' in caso di
>>> fallimento, a quel punto é il client che deve gestire l'idempotenza...
>>
>>
>> Capisco, ma quando fa la richiesta sincrona non restituite niente? Solo
HTTP/200? Nemmeno un ID che poi ripassate nella notifica asincrona?
>>
>> Se ad esempio un cliente chiama
>>
>> addebita 2 euro sul numero 3334455667 (relativo ad un servizio A)
>> addebita 2 euro sul numero 3334455667 (relativo ad un servizio B)
>>
>> e voi non restituite niente sulla richiesta sincrona poi quando
ricevera' la notifica asincrona non sapra' piu' come distinguere le due
notifiche. Oppure nella richiesta puo' specificare un suo ID che dopo si
ritrova nella notifica?
>
>
> Quest'ultima.  Nella richiesta /deve/ specificare un'id, altrimenti non
possiamo restituire una risposta asincrona.
>

Stiamo mischiando 2 problemi qui: idempotenza della richiesta e
correlazione della notifica che verrà fatta.

Il primo problema si risolve con un id di richiesta generato e passato dal
client, che in caso di retry lo ripassa. Internamente usiamo gli ObjectId
di MongoDB ad esempio, oppure UUID.

La correlazione della notifica può utilizzare l'id della richiesta visto
che é già disponibile. Può anche avere un id remoto ritornato nella
risposta sincrona, ma é un po' più laborioso perché la notifica potrebbe
arrivare prima che tu possa registrare l'id remoto ed essere quindi
rifiutata, necessitando anche lei di retry.
-------------- parte successiva --------------
Un allegato HTML è stato rimosso...
URL: <http://ml.grusp.org/pipermail/milano-grusp.org/attachments/20140916/96d66747/attachment-0001.htm>


Maggiori informazioni sulla lista Milano