Motivi per NON utilizzare la posta elettronica per l'integrazione del sistema

How do I nicely explain to a customer that if the message is really critical and time sensitive then email (SMTP) is NOT the way to do it.

Sapendo perché non lo è.

Indica un bisogno reale che la soluzione email non può risolvere.

Posso indovinarne alcuni. HTTPS è abbastanza buono per comunicare in modo sicuro e dimostrare che stai parlando con chi pensi di parlare. Ma sono queste le reali esigenze del tuo cliente?

I clienti di solito sono facili da convincere che sai come fare ciò che vuoi fare. Sono già convinto che tu sappia come creare un'API riposante e non ti conosco nemmeno.

Quello che non so è che capisci davvero le esigenze dei tuoi clienti. Se stai cercando di dissuaderli dall'utilizzo della posta elettronica, devono esserci alcuni motivi per cui sono favorevoli. Forse l'hanno già usato prima. Forse lo capiscono abbastanza per fidarsi di esso e in qualche modo mantenerlo. Se li passi a REST, cosa stai portando via da loro?

Ho lavorato in sistemi che utilizzano l'e-mail esattamente come il cliente sta descrivendo. Sembra che sia tenuto insieme al cavo di salvataggio. Ma può funzionare.

Anche l'email manuale può essere critica e sensibile al tempo. La gente lo usa comunque. Certo, il tuo cliente non ha altre esigenze che un'API funzioni meglio di un parser email? Forse parlarne.

Sono d'accordo con tutto CandiedOrange menzionato (compreso il come spiegare x a y commento). Riguarda le esigenze dei clienti. Ho costruito sistemi che si basano su e-mail smtp. Funziona bene e si adatta alle esigenze dei clienti. E per quanto ne so, continua ancora, anche adesso, 7 anni dopo.

Tuttavia, c'è uno svantaggio qui, come vedo io. Ed è la risposta.

In una richiesta http la risposta è data direttamente. A meno che non stia usando il fuoco e dimentichi, ma teniamolo da parte per ora come i servizi più riposanti no. Il chiamante può immediatamente sapere se il ricevitore ha ricevuto la chiamata. Questo non è realmente possibile (per quanto ne so) con SMTP. In questo modo puoi gestire gli errori nella comunicazione più velocemente con http (s).

Quindi, in teoria, il chiamante dovrebbe essere in grado di ottenere una conferma dal ricevitore più veloce (leggi: direttamente) se stai usando http (s) che con SMTP. Tuttavia, non c'è davvero garanzia che una richiesta http sia più veloce di smtp.

Un'altra cosa da considerare è la dipendenza dal server di posta, ad es. Scambio. Cosa succede se va giù o deve ricominciare? Se i due sistemi dipendono l'uno dall'altro, c'è una cosa in meno di cui preoccuparsi quando si applicano gli aggiornamenti e si considera il tempo di inattività.

Non lo fai!

Assicurati che il cliente sia consapevole delle distinzioni:

Le email sono intrinsecamente ottimistiche e sono intrinsecamente asincrone. Quando il client invia un messaggio, assume che il destinatario riceve ed elabora. I guasti non sono necessariamente segnalati. E quei guasti che sono riportati non vengono sempre riportati al mittente. E a volte non possono essere - come se il mittente utilizza un indirizzo return-to di buco nero.

Al contrario, poiché HTTP è progettato per il recupero di documenti, le API che si eseguono su HTTP possono e generalmente rispondono immediatamente con codici di successo dettagliati e messaggi direttamente al cliente. E anche se l'elaborazione di messaggi asincroni è ancora un'opzione, è molto più in linea con HTTP che i client ricevano immediate operazioni success / fail se sono necessarie.

Potrebbero esserci altre cose importanti da segnalare. Uno di questi potrebbe essere: "Posso sviluppare le API REST più velocemente, b / c è ciò che faccio normalmente". E quei punti non sono invalidi. Ma non sono ragioni tecniche . Sono realtà pratiche.

Ma fondamentalmente è così. Se sei abbastanza competente per lavorare in entrambi i casi, per lo più devi solo decidere con il cliente se l'integrazione necessita di un'elaborazione degli errori immediata o se le macchine client possono tranquillamente ignorare gli errori.