Functional Spec
Platform should have an API to allow ability to send an SMS to a client or a staff.
Discussions have identified that to prevent abuse and ensure traceability, we would would NOT want the REST API to expose a send(String phoneNumber, …) kind of semantics, only send Client or Staff.
Q1: To help understand API usage can we identify some possible example ways that application developers would use this API on their screens/workflows?
Note: There are also many cases (e.g loan enters delinqent state, meeting notification) where the platform itself internally would/may want to send SMS automatically to Clients/Staff. It would/may not use the API itself but its underlying implementation.
Tech Spec
API Level:
In mailing thread, Michael Vorburger offered some suggestions on possible API to expose. Mainly Michael focussed on a generic or abstract api whereas my preference is for something less abstract. The apigee ebook on web apis that we reference in our API documentation goes into explanation of why staying away from abstract apis would be a good idea.
So to start with something as simple as:
POST /sms
GET /sms
GET /sms/{smsIdentifier}
POST /sms
{
"message": "some text content that makes up the sms.",
"clientId": 1,
"staffId": 1
}
Some questions that arise staightaway:
Q. Do we want to attempt to send the SMS straightaway of offer ability to indicate when the SMS could be sent?
Note: In terms of response, we wont be waiting around for third party service to respond to us, we will just make entry into our database, attempt to send sms and respond back to api caller that SMS entry made successfuly (or not) and any extra information that might be useful like 'status'.
Database Schema
No problem with modelling for more abstract 'messages' functionality here if you want to e.g. not just sms but other forms of messages/notification event but for now theres no problem with just creating a table to track sms only messgages. We dont need to split them up into client and staff (no real help) and we can still have proper foreign keys, just create client_id and staff_id column - if we think there will be many entities in the system associated with 'mobile numbers' and are sms-able then we would just go with the entity type, entity id approach.
The needed fields themselves will become very obvious when padding this out.
Batch processing
We probably want to be able to:
- Send SMS straightaway, or
- let some batch or scheduled process check for SMS entries that require sending