Software Engineering Stack Exchange is a question and answer site for professionals, academics, and students working within the systems development life cycle. It only takes a minute to sign up.
Sign up to join this community
I do system integration for critical and time sensitive systems. We have two standard ways we can build these system integrations. One is a simple (and cheap) email ingestion tool built into our platform and the other is a very customized (expensive) standalone HTTPS Restful API integration.
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.
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.
By knowing why it's not.
Name one real need that the email solution can't solve.
I can guess at a few. HTTPS is fairly good at securely communicating and proving you're talking to who you think you're talking to. But are those real needs for your customer?
Customers are usually easy to convince that you know how to do what you want to do. I'm already convinced you know how to make a Restful API and I don't even know you.
What I don't know is that you really understand your customers needs. If you're trying to talk them out of using email there must be some reason they favor it. Maybe they've used it before. Maybe they understand it enough to trust it and somewhat maintain it. If you switch them to REST what are you taking away from them?
I've worked in systems that use email exactly the way your customer is describing. It feels like it's held together with bailing wire. But it can work.
Even manual email can be critical and time sensitive. People use it for that anyway. Sure your customer doesn't have other needs that an API works better for than an email parser? Maybe talk about those.
I agree with everything CandiedOrange mentioned (including the how to explain x to y comment). It's all about the clients needs. I've built systems that rely on smtp email. It works fine and it suited the clients needs. And as far as I know it still runs, even now 7 years later.
However, there is one downside here, as I see it. And it's the response.
In a http request the response is given directly. Unless it's using fire and forget, but let's keep that aside for now as most restful services don't. The caller can immediately know if the receiver got the call. That is not really possible (as far as I know) with SMTP. This way you can handle errors in the communication faster with http(s).
So, in theory, the caller should be able to get a confirmation from the receiver faster (read: directly) if you're using http(s) than with SMTP. However, there's really no guarantee that a http request will be faster than smtp.
Another thing to consider is the dependency to the mailserver, eg. Exchange. What if it goes down or has to restart? If the two systems only depend on each other there's one less thing to worry about when applying updates and considering downtime.
You don't!
You just make sure the client is aware of the distinctions:
Email is more inherently optimistic, and it's more inherently asynchronous. When the client sends a message, it assumes the recipient receives and processes it. Failures aren't necessarily reported. And those failures that are reported aren't always even reported back to the sender. And they sometimes can't be -- like if the sender uses a black-hole return-to address.
On the contrary, because HTTP is designed for document fetching, API's that run over HTTP can and generally do respond immediately with detailed success codes and messages directly to client. And while asynchronous message processing is still an option here, it's much more in-line with HTTP for clients to receive immediate success/fail operations if those are needed.
There may be other important things to point out. One of those might be, "I can develop REST API's faster, b/c it's what I normally do." And those points aren't invalid. But, they're not technical reasons. They're practical realities.
But, that's basically it. If you're competent enough to work it either way, you mostly just need to decide with the client whether the integration needs immediate failure processing, or whether the client-machine(s) can safely ignore errors.
