Fredrik L
Fredrik L

Reputation: 1800

rest api design -> email notification

Is it bad practice to do automatic notification (email/sms/etc) as part of an api call? Or should that be separated from the core functionality.

Say I update a project status and want to send notification to all users watching the project. Can I do that from the update call or should I break it out into some other notification mechanism? Any thoughts? If doing it from the call I guess each relevant method would need an option of skipping sending notifications.

Upvotes: 4

Views: 2233

Answers (2)

Yuriy Zubarev
Yuriy Zubarev

Reputation: 2871

I would add to a response by Rafael Mueller that there is a difference between RESTful interface and implementation mechanics.

As far as RESTful interface is concerned here are my thoughts. Let's say you update a project status with "PUT /project/123/status". Whether email is going to be send or not it's up to a value proposition of your app. May be that's how you want to differentiate yourself from your competitors.

Let's say you support sending of emails but you want to give control to a client on a call-by-call basis. I would go with an optional HTTP Header or an optional attribute of the request body be it JSON or XML or anything else.

Once you allowed variability in emailing project status, I would advice to design a designated end-point to trigger email update on demand. Something like "POST /project/123/status/send-email". This way your client won't shoot itself in a foot: if they forgot to send email during a project status update, or simply changed their mind, they can always call "send-email".

Upvotes: 7

Rafael Mueller
Rafael Mueller

Reputation: 6083

I would rise an event, ProjectUpdated, you can add it to your messaging system (a database could solve, or rabbitmq, msmq...) and the consumer of this event, will send the email.

Upvotes: 3

Related Questions