Schema/API Design comments Krishnanshu Gupta

user_id is being used in several tables, so there should be a new table created for users that contains some information about them. There is a user_test table, but in that case, user_id should be foreign key when used in other tables.
For /reviews/new, and in the review table, consistent naming pattern should be followed. Everywhere else, 'name' is used, so consider changing 'author_name' to 'name', to match.
The route table has quite a few columns which can be split down into several tables to make a more focused table structure. For example, you could create a separate table called route_activities table that has information on the activities of a route, which can be accessed through route_id.
/routes/add doesn't match the APISpec. The actual code is missing "date_added" from the APISpec request list, and some of the naming is also incorrect, such as discrepancy between user_added and user_id, length_in_miles and length.
/routes/report doesn't match the APISpec. The request should be this according to the spec:
```
[
{
"route_name": "string",
"date_added": "string",
"date_reported": "string",
"report_author": "string",
"coordinates": [lat, long],
"description": "string",
}
]
```
However, the code itself takes in a parameter of type Routes which is mismatched. Might benefit from making a new class for reports.
/routes/popular doesn't match the APISpec. The actual code doesn't get the necessary information for the user_added, the popularity_index, five_star_reviews, which is specified in the spec.
/routes/friends in the APISpec is actually /routes/followers within the code. Either the code or the spec should be changed to match the naming.
/reviews/new in the APISpec is actually /reviews/add within the code. Code in reviews.py or the spec should be changed to match naming. Additionally, the return type should be "success": boolean, but code is actually returning just "OK".
The API specification has no references to the /business/add or /coupons/add within the businesses.py and coupons.py files respectively.
None of the code in users.py matches the APISpec for section 1, User Social Network. The functionality is similar but the requests are completely different from the actual code and the naming is also different. Spec should be updated to match the users.py class.
This line: constraint review_user_id_fkey foreign key (user_id) references "user" (id), doesn't make sense to me as there's no user reference anywhere.
/peepcoins/purchase/coupon doesn't match the APISpec definition. The code should be returning a boolean for the success and a string for the transaction_details, but it only returns "OK".

n-shinde / PeakPeeps

Schema/API Design comments Krishnanshu Gupta #18