The API for this project allows a user to report up to 3 medical symptoms and their severity they are experiencing via SMS. It also allows an admin to view all the registered users, their info and the symptoms they recorder along with their severity.An admin can also unsubscribe (delete) an existing user. The API uses MongoDB Atlas cloud database, Digital Ocean Ubuntu droplet for hosting our API and Twilio to enable SMS service.

The end points are as follows:

1. POST: http://64.227.27.167:1337/api/v1/sms
2. GET: http://64.227.27.167:1337/api/v1/login
3. GET: http://64.227.27.167:1337/api/v1/admin/users
4. DELETE: http://64.227.27.167:1337/api/v1/admin/users/<user_id>
5. GET: http://64.227.27.167:1337/api/v1/admin/profile

Before any or some of this functionality is provided, this API will execute some custom middleware as discussed below:

1. Connecting to Database: Before hitting any of the above listed endpoints, our API needs to connect to our MongoDB Atlas database to retrieve/save/delete/update data. This middleware will establish this connection with the database using a database URL before processing any request. If the connection is established, the request will forward to the intended endpoint or the next middleware (as suited for the specific case), otherwise an error response will be returned to the users specifying that the database connection cannot be established.

2. Authenticating user:

Login is required only for accessing the admin portal. Users communicating with SMS need not authenticate themselves. Hence endpoint 1 will not need authentication. This middleware will execute only for admins who are logged into the system using the login functionality. Whenever an admin tries to access any of the above mentioned endpoints (2-5), a JWT bearer token needs to be specified in the Authorization header in the request along with other endpoint specific data. This middleware will check for this token. If the token is not found in the request or has elapsed the duration of 24 hours since its issuance then an error response will be sent to the admin with an appropriate response, otherwise on successful validation of the token, the API will then proceed to fulfill the request using the appropriate endpoint or go on to the next middleware as suited for the specific case. The JWT is created and validated in the API using jsonwebtoken library of node. Every token issued after username and password login has 60 minutes time to live, after which the token will be treated as invalid.

3. Authorizing admin: This middleware will execute only for endpoints beginning with '/api/v1/admin' pattern. It will make sure that users trying to use the endpoints with the mentioned pattern as essentially admins by role. The token decoded while authenticating the user will be checked for its role parameter in this middleware. If a role is not found or if found is anything else than admin, then an error response is sent back to the user. If the decoded token value has role as admin, it will go on to fulfill the user request by hitting the intended endpoint.

Let's now discuss the API end points in details:

1. POST: http://64.227.27.167:1337/api/v1/sms

Body:
 {
     ToCountry: 'US',
     ToState: 'OH',
     SmsMessageSid: 'SM7f8cb8945d1bf773d7b8be120cf14fcf',
     NumMedia: '0',
     ToCity: 'FLETCHER',
     FromZip: '10010',
     SmsSid: 'SM7f8cb8945d1bf773d7b8be120cf14fcf',
     FromState: 'NY',
     SmsStatus: 'received',
     FromCity: 'NEW YORK',
     Body: 'Hello',
     FromCountry: 'US',
     To: '+19373684288',
     ToZip: '45504',
     NumSegments: '1',
     MessageSid: 'SM7f8cb8945d1bf773d7b8be120cf14fcf',
     AccountSid: 'AC4795b2534203c3773f137726ffe95b28',
     From: '+16462093271',
     ApiVersion: '2010-04-01'
}

This is the POST endpoint registered with Twilio to communicate with the server whenever an sms is received on its registered number. Whenever the registered Twilio number is sent an sms from a user, a body like the one mentioned above is sent to this endpoint. The server then parses this data and depending upon the received message responds by sending an appropriate response message body to Twilio. Twilio will then forward this text message from the server to the number from where the original message was received. In the above mentioned body, the text message from the user is provided in the Body parameter, the number from the message came is provided in From parameter and the number to which the message was sent (Twilio registered number) is provided in To parameter.

• In this end point, a new user will get registered on the server by texting START (not case sensitive). A users who is already registered will not be allowed to register again.
• Upon being registered, the user will be welcomed to the service and will be sent an sms providing a list of symptoms to select from (numbered list having (1)Headache, (2)Dizziness, (3)Nausea, (4)Fatigue, (5)Sadness, (0)None).
• Upon selecting a symptom by texting a relevant number, another message will be sent to the user asking them to rank the severity of the symptom , 0 being none to 4 being severe
• When a user sends a relevant ranking of severity, the symptom along with the severity ranking is recorder against the user and the user is sent a relevant diagnosis for the symptom and severity via sms.
• Now list of symptoms is again sent to the user, now by omitting the already recorded symptom. Hence the procedure will start again from step 1 and continue as it does. This will go on till the user has registered 3 symptoms and their severity ranking or has texted 0 (None) while presented with the list of symptoms to select from. Once either of these conditions is met, the user is done recording symptoms and getting diagnosis. The user cannot start the cycle again after this as they are already registered and done, until and if they are unregistered by the admins.
• Any improper input at any step is handled appropriately by sending a correct validation sms to the user.
• Unregistered users texting anything other than start to the app will be informed that they are not registered users and that they need to text START to do so.
• Users texting start after registering will be informed that they are already registered with app and cannot do so again.
• Users texting anything but start after their symptom evaluation is done will be texted that they are done with their evaluation.

2. GET: http://64.227.27.167:1337/api/v1/login

Header:
{Authorization:Basic <base64encoded_email:password>}

This endpoint allows an admin to login using email and password. If the authorization header type is encountered to be 'Basic', then the end point checks if the user with the given email id exists in the system or not and if they do, is the correct password provided for the user. If the user has provided proper and existant login credentials, then the user is returned in the response along with a jwt token having a ttl of one hour. Otherwise, an error response will be returned. In order to check if the incoming password matches the password present in the database for the specific user, this password is hashed and salted and compared to the hashed and salted password present in the database. This is done using bcrypt.js.

3. GET: http://64.227.27.167:1337/api/v1/admin/users

Header:
{Authorization:Bearer <token>}

This endpoint allows an admin to fetch all registered users in the database. It fetches the phone number associated with every user, the date of the user registration to the app and all the symptoms recorded by the users to the app along with the severity ranking of each symptom. Only a user with admin token can access this endpoint.

4. DELETE: http://64.227.27.167:1337/api/v1/admin/users/<user_id>

Header:
{Authorization:Bearer <token>}

This endpoint allows an admin to delete/unsubscribe a user from the system. An appropriate user_id needs to be provided in the URL in order to locate the user who is to be deleted from the system. If an incorrect ID is provided in the URL or if the ID is not present in the database, then an appropriate error response in sent back to the admin user. Otherwise the user is deleted successfully and a message is sent accordingly to the admin. Only a user with admin token can access this endpoint.

5. GET: http://64.227.27.167:1337/api/v1/admin/profile

Header:
{Authorization:Bearer <token>}

Only a user with admin token can access this endpoint. It returns the user info (except for password) from the token provided in the authorization header. If a user corresponding to the user id found in the decoded token is not found in the database, an appropriate error is returned back to the user.

We have used MongoDB database for our application. The database resides on an Atlas cloud cluster.

1. The database has an admins collection which will store the following fields when an admin is created.

Database schema

• _id : This is the unique id generated by mongoDB automatically for the record entry.
• name : name of admin
• email : Email ID of admin. This is a unique field, hence no two records can have the same email id (since it is used for user login)
• password : Hashed and salted value of admin password.
• role : Role of the admin in the system.

2. The database also has a users collection which will store the following fields

Database schema

• id : This is the unique id generated by mongoDB automatically for the record entry.
• phoneNumber : Phone number of registered user
• date : date when the user was registered
• step : the step number which the user is currently performing/is in
• history : array of symptoms and their severity ranking recorded by the user
• currentSymptom : current symptom number registered by the user
• userState : current user state (array of symptoms given to the user to pick/ Done status)

the history attribute is a list of symptoms and their severity ranking recorded by the user. They have following data:

Database schema

• symptom : name of the recorded symptom
• severity : severity ranking of the symptom

Twilio key is saved on the server for maintaining its privacy.