Final Project: Blabber backend
Contents
Due dates
- an initial database model (in UML) is due Tuesday, November 18, 2014 at 11:59pm
- at least three API action functions are due Friday, November 21, 2014 at 11:59pm
- your files on the server will be snapshotted on Sunday, December 14, 2014 at 11:59pm
Introduction
The goal of this project is to give you experience with modeling information for a web application. You will use several industry standard technologies, namely:
- PHP
- PostgreSQL
- MongoDB
- JSON
You will be given the requirements for an application programming interface (API), which you will have to implement using PHP, PostgreSQL, and MongoDB. Your PHP files will act as the interface between the front end and the databases. You will not be designing the front end for your project, unless you want to for extra credit.
There are many tools that you will need to learn along the way, and we will use class time to go over those tools.
You may work with up to two other students from the class on this project. All members of your group are expected to perform an equal share of the work.
(Back to top)Blabber
The project will consist of implementing an API (see the next section) for a micro blogging web site (think Twitter). We'll refer to the system as Blabber. Blabber has three parts:
- a web interface front end
- an API layer on the back end
- a set of databases on the back end
The web interface, which you will not have to program, will allow a user to:
- sign up
- sign in
- sign out
- change info
- blab
- re-blab an existing blab
- like a blab
- search blabs
- follow other Blabber users
- list everyone they are following
- unfollow someone they are following
- list everyone following them
- view other members along with:
- their followers
- who they are following
- how many users they are following
- how many of their blabs have been re-blabbed
- how many of their blabs have been liked
- their blabs
API
The API will be exposed via a single PHP file and parameters passed to it via POST (more on that later). That file will be called blabber.php and should be located in the public_html/csc340-final-project directory of one of your group member's home directory on the server (e.g., /home/hfeild/public_html/blabber.php). This will be accessible via the web at: http://joust.cs.endicott.edu/~USER/csc340-final-project/blabber.php, where USER is your group member's username (e.g., for me, it would be hfeild).
You should download the simple frontend to that public_html/csc340-final-project directory. You can do this by running the following command from said directory:
wget http://hank.feild.net/courses/2014-fa/csc340/hw/blabber-frontend.html
In PHP, POST parameters can be accessed via an associative array like this:
All API functions will have, at a bare minimum, one parameter:
- action (string)
The latter two will hold the user's username and password. The former will be one of the following, and should assume the list of associated parameters (some of which are optional, as indicated).
If there is an error processing any actions, including unrecognized actions, the API should return an error message formatted in JSON as follows:
(Note: the angled brackets represent place holders!)
Here's a listing of all the actions (you can click on one to bring you to the section).
(Back to top)action:signup
Assumes the following additional parameters:
- username (string)
- password (string)
- displayName (string)
- handle (string)—must be unique!
Also, note that the username parameter must be unique during signup; that is, no existing user may already have that username. If either the username or the handle already exists, you must return an error message. The output should be returned in JSON format; if the sign up was successful, return:
(Back to actions)action:signin
Assumes the following additional parameters:
- username (string)
- password (string)
This is used to notify the server that the user has signed in. One of three things should happen after the user has been authenticated:
- if no session cookie exists, create one and add the username to the cookie
- if a session cookie already exists and the username is different, sign that user out first, then follow the steps in option 1
- if a session cookie already exists and the username is the same, return an error message saying "User already signed in".
The cookie should be used for all other actions (other than signup) in place of authenticating the user. If, for another action other than signup, a session cookie with a username does not exist, an error should be returned with the content: "User not signed in.".
The response for this action should be in JSON format; if the sign in was successful, return:
(Back to actions)action:signout
Assumes no additional parameters. This is used to notify the server that the user has signed out. The response should be JSON format; if the sign out was successful, return:
(Back to actions)action:changeInfo
Assumes the following additional parameters:
- displayName (string) OPTIONAL
- handle (string)—must be unique! OPTIONAL
- currentPassword (string) OPTIONAL (but required if newPassword is included)
- newPassword (string) OPTIONAL
Information can only be changed for the user specified by username (i.e., one user cannot change the information of another user). The user may update one or all of these parameters. Un-specified parameters should maintain their current values in the database(s).
The output should be returned in JSON format; if the info change was successful, return:
(Back to actions)action:getUserInfo
Assumes the following additional parameters:
- handle (string)
This should retrieve all of the publicly available information about the user associated with handle. This can be the same as the current user's handle, or some other user.
The output should be returned in JSON format; if the info change was successful, return:
(Back to actions)action:blab
Assumes the following additional parameters:
- contents (string)
This function should save the first 300 characters of the given contents string to the database. If successful, the returned output should be formatted as:
(Back to actions)action:getBlabs
Assumes the following additional parameters:
- since (timestamp)
- handle (string)
This will retrieve all saved blabs blabbed by the user with the given handle since the given timestamp. If the given handle was valid, the return value should be formatted as:
Where blabs can consist of a mix of blabs and reblabs. A blab is formatted as:
And a reblab is formatted as:
The list of blabs should be sorted chronologically, newest to oldest. Each blab must have a unique id (across all users and blabs). In a reblab, the balbbedOn field corresponds to the time it was reblabbed. Note that the reblab must contain the original blab as a field.
(Back to actions)action:reblab
Assumes the following additional parameters:
- blabID (id)
This will reblab the blab with the given id. If the given handle was valid, the return value should be formatted as:
(Back to actions)action:like
Assumes the following additional parameters:
- blabID (id)
This will add a 'like' to the blab with the given id. If the given handle was valid, the return value should be formatted as:
(Back to actions)action:search
Assumes the following additional parameters:
- query (string)
- handles (list of strings, comma separated) (OPTIONAL)
Searches blabs for the given query text. If the handles parameter is provided, then only blabs blabbed or re-blabbed by users whose handles are listed are searched. The results should be returned to the user in the format:
(Back to actions)action:follow
Assumes the following additional parameters:
- handle (string)
Adds the given handle to the user's list of followers. The results should be returned to the user in the format:
(Back to actions)action:getFollowing
Assumes the following additional parameters:
- handle (string)
Produces a list of the handles the given handle is following. The results should be returned to the user in the format:
The output should be read as: this user (handle) is following this list of users (following).
(Back to actions)action:unfollow
Assumes the following additional parameters:
- handle (string)
Removes the user from the followers list of the user with the given handle, and removes the user with the given handle from the user's following list. The results should be returned to the user in the format:
(Back to actions)action:getFollowers
Assumes the following additional parameters:
- handle (string)
Produces a list of users following the given handle. The results should be returned to the user in the format:
The output should be read as: this list of users (followers) are following the user with this handle (handle).
(Back to actions)Requirements
You must keep track of the data being created (e.g., users, blabs, etc.) as well as all of the actions taking place. By storing all of the interactions (e.g., API requests), the Blabber overlords can decide to engage in some juicy analytics down the road and find interesting trends, etc. Every logged event should include a timestamp. It is up to you to decide whether to use a PostgreSQL or MongoDB database.
For the relational database, you must have the following:
- SQL transactions where appropriate (*cough,cough,everywhere,cough*)
- at least two SQL views
- at least one SQL index (not including the default primary key indexes)
- at least one trigger
- at least two constraints
For each API request (other than signin and signup), you must verify that the user is logged in. For the signin action, you must authenticate the user by ensuring username is a valid user and that password is the correct password. You should combine the password with a user-specific, randomly generated salt value and store the hash of the combination (e.g., MD5 or SHA-256). If the credentials are invalid, you should return and error message. API access calls that result in errors should still be logged.
(Back to top)Skills
There are several skills you need to have in order for your project to be successful. Between now and the project due date, we will spend class time learning these skills and applying them to your project. Here are some of the tools:
- Unix tools
- ssh
- scp
- vim
- wget
- cd
- mkdir
- PHP
- PostgreSQL
- MongoDB
- Submissions
- Version control (using git)
Submissions
You will not submit anything, per se. Instead, you will need to make sure that the following materials are present in the directory /home/USERNAME/public_html/csc340-project before the deadline. That directory only needs to exist for one of the members of your group. The submission directories will be automatically collected at the deadline.
The materials you need to submit are:
- a project write up, which consists of a description of who in the group did what tasks and a detailed discussion of your design decisions for the project; this can be a text file or a PDF
- a database diagram for all databases you used; this should include all tables, fields, types, and the relationships between entities
- well-styled and documented code for the API
Extra Credit (10 points)
The purpose of this project is to demonstrate your ability to model information, store and access data from different types of databases, and use PHP to perform the interactions. The front end is out of the scope of this class. However, if you would like to, you can get up to 10 extra credit points if you beautify the front end so that the site resembles a modern web site. You can use HTML, CSS, JavaScript, and whatever else you would like. If you do the extra credit, be sure to inform me so that I know to look for it. Include the web address of your front end.
(Back to top)Rubric
| Database Design | The diagrams are clear and all of the information is well modeled. There is a reasonable organization and the relational databases are in 3NF. (30pts) | The diagrams are somewhat unclear. Not all of the information is modeled, or is modeled in correctly. The organization is not reasonable and some tables include redundant information. (15pts) | The diagrams were not submitted or are extremely messy. Little or no information is modeled correctly. Redundancy is rampant. (0pts) |
|---|---|---|---|
| Database Implementation | The PostgreSQL tables are set up correctly. Data is stored and accessed in PostgreSQL and MongoDB in an efficient fashion. Data is stored using best practices. (30pts) | There are some issues with the way tables are set up in PostgreSQL. Data is not accessed in the most efficient manner from either PostgreSQL or MongoDB. Data is not always stored using best practices. (15pts) | The PostgreSQL tables are not proper set up at all. There is no attempt as efficiency. (0pts) |
| PHP | The PHP code is clear and efficient. It is well documented and formatted correctly. (10pts) | The PHP code is somewhat unclear and difficult to read. Some parts are not efficient. Documentation is lacking and there are formatting issues. (5pts) | The PHP code is a mess. There is not attempt at efficiency. Documentation is sparse or not present at all. Formatting was thrown to the wayside. (0pts) |
| API Implementation | The API works as described in the project description. All the data is returned in correct JSON format. (30pts) | Some of the API works as required. The returned data is not quite in the correct format. (15pts) | The API does not comply with the requirements. The data is not returned in the correct JSON format. (0pts) |
| Extra credit | The front end works smoothly, looks modern, and provides access to all of the API features. (10pts) | Aspects of the front end are not smooth or seem too simple. Not all API features are accessed. (5pts) | No front end was provided, or the front end is not smooth, modern, and does not access most API features. (0pts) |
| Total: | 100pts + 10pts EC |