User Passwords: Storing passwords in plain text is a security risk. Hash passwords before storing them in the database or use some of the other techniques we learned in class last week.
User Type: The user_type field in the users table is an integer. Consider using an ENUM type for better readability. Also be more clear in the code of what user_type actually is and within the API docs.
Venue Name: The name field in the venues table is a timestamp. This seems like a mistake and should be corrected to a text type.
Foreign Keys: The performer_id and venue_id fields in the bookings table should have foreign key constraints to ensure data integrity.
Capacity Preference: The capacity_preference field in the performers table is nullable. If this field is important for the booking process, it should be set to NOT NULL. Depends on how you want to continue on with the project.
API Design Improvements:
Endpoint Naming: Small thing but the endpoint /book/create/request_venue/{performer_id} could be simplified to /bookings/{performer_id}.
HTTP Methods: The Create Booking endpoints use POST, but it might be more appropriate to use PUT since the performer_id is part of the URL.
Input Validation: The API specification does not mention any input validation. You probably should validate inputs to prevent invalid data from being added to the database.
Error Messages: The API should aim to return descriptive error messages to help clients understand what went wrong when a request fails.
API Versioning: The API does not use versioning. Adding versioning to your API can help maintain backward compatibility when you make changes to the API (might take a while to implement, up to you to decide if this is necessary).
Timestamps: The time_available and time_end fields in the performers and venues tables are timestamps without timezone. It would be better to store these as timestamps with timezone to avoid confusion and errors due to time zone differences.
Price Fields: The price fields in the performers and venues tables are integers. Change these fields to a decimal or float type if you want to allow fractional prices.
Schema Improvements:
User Passwords: Storing passwords in plain text is a security risk. Hash passwords before storing them in the database or use some of the other techniques we learned in class last week.
User Type: The user_type field in the users table is an integer. Consider using an ENUM type for better readability. Also be more clear in the code of what user_type actually is and within the API docs.
Venue Name: The name field in the venues table is a timestamp. This seems like a mistake and should be corrected to a text type.
Foreign Keys: The performer_id and venue_id fields in the bookings table should have foreign key constraints to ensure data integrity.
Capacity Preference: The capacity_preference field in the performers table is nullable. If this field is important for the booking process, it should be set to NOT NULL. Depends on how you want to continue on with the project.
API Design Improvements:
Endpoint Naming: Small thing but the endpoint /book/create/request_venue/{performer_id} could be simplified to /bookings/{performer_id}.
HTTP Methods: The Create Booking endpoints use POST, but it might be more appropriate to use PUT since the performer_id is part of the URL.
Input Validation: The API specification does not mention any input validation. You probably should validate inputs to prevent invalid data from being added to the database.
Error Messages: The API should aim to return descriptive error messages to help clients understand what went wrong when a request fails.
API Versioning: The API does not use versioning. Adding versioning to your API can help maintain backward compatibility when you make changes to the API (might take a while to implement, up to you to decide if this is necessary).
Timestamps: The time_available and time_end fields in the performers and venues tables are timestamps without timezone. It would be better to store these as timestamps with timezone to avoid confusion and errors due to time zone differences.
Price Fields: The price fields in the performers and venues tables are integers. Change these fields to a decimal or float type if you want to allow fractional prices.