When building a service that uses both a back-end REST API, and (a) front-end application(s), is it proper to build into that API the ability to dispatch email?

Take Twitter for example; for those who don't know, they function with a back-end REST API and a front-end static website that consumes JSON resources.

I don't know their internals, so I really don't know how to handle this situation for myself, however obviously they do allow users to sign up, register, recover their passwords, confirm their accounts, et cetera. Most of these things require an email to be dispatched to the user. Does the API do that, or how is this implemented?

  • It's implemented by code in the Twitter Server. What are you asking, exactly? If all a REST API could do is update records in some database, it wouldn't be very interesting. Mar 25, 2016 at 2:57
  • 3
    Eh, I always wince when folks ask "Is this the proper way" or "Is this the correct way." While folks like yourself spend time figuring out how to be "correct," the rest of us are getting actual work done. Have a look here: stackoverflow.com/questions/16877968. It not only says "yes, you can," but describes in nauseating detail why it is "correct" to do so. Mar 25, 2016 at 3:02
  • 1
    @RobertHarvey Thanks for the extensive link. I apologize (I suppose?) for asking a question on a site dedicated to these types of questions :-) Have a good one. Mar 25, 2016 at 3:07
  • 2
    @svidgen: The "right" way is the way that most effectively fulfills your software's functional and non-functional requirements. The analysis that results from that simple premise should satisfy maintainability and performance concerns, while still allowing for "best practices" without becoming cargo-cult. Mar 25, 2016 at 19:56
  • 1
    @svidgen: There's a difference between knowing a rule from experience, and blindly following a rule without understanding it just because someone else said so. And some of these folks spend inordinate amounts of time trying to be "right" without first understanding the issues. If you have to ask "which hammer should I use to fix this roof," then you don't know enough yet to fix the roof. Mar 25, 2016 at 20:09

3 Answers 3


Sure. Why not?

When you invoke a REST service, you're transferring state. It's up to the software on both ends to determine what actions the deltas ultimately demand.

The general exception would be for the safe methods like HEAD, GET, OPTIONS and TRACE, which should generally produce no side effects.

And as an exception to the exception, even for the safe methods, if your API received "too many" requests or detected other suspicious requests, you'd potentially want to have a side effect like revoking access and/or dispatching an email to a security admin.

  • You shouldn't use PUT, either. Which pretty much leaves POST, for what the OP wants to do. Mar 25, 2016 at 20:12
  • We shouldn't use PUT? Says who!?
    – svidgen
    Mar 25, 2016 at 20:49

At it's heart, REST is just a mapping of CRUD operations onto HTTP verbs - it's an interface to communicate with a server. I don't think there's any expectation that calling a POST action for example should be side effect free, so don't see any problem with that being the trigger for some back-end workflow including emails.


Probably not.

On larger projects, no, from my experience, it would not be typical that whatever script or process is on the server side of the REST request would actually send email. More often than not, it might generate information about the email, but then stick it into a database or queue for a dedicated email process to send. This allows applications to throttle the rate of outgoing emails, as well as handle problems that come up (resend) and logging.

Mind you, along the lines of what Robert Harvey brings up in comments, what is proper or not is completely situational. What is appropriate for Twitter is not the same as what is appropriate for a "Scarecrow and Mrs King" PHPBB Forum with 12 members. On smaller sites, sure, the script on the server side of the REST request can do the emailing itself. Its probably a lot simpler than creating a dedicated process to handle 3 emails a week. But as that grows, the functionality will probably move to more dedicated processes.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.