P4 – Prototype Implementation (REST API)

Description

This phase focuses on the implementation of a functional backend prototype for the Wedding Planner system. The prototype demonstrates the practical use of the database designed in previous phases through RESTful endpoints.

The implementation validates the relational schema and business logic by exposing selected functionalities via a Flask-based REST API connected to an SQLite database.

Technologies and Tools

The prototype is implemented using the following technologies:

Python 3.11

Flask web framework

SQLite relational database

SQL schema and seed scripts

Flask development server (local execution)

Prototype Architecture

The backend prototype consists of:

An SQLite database created using SQL DDL scripts

Pre-populated sample data using seed scripts

A Flask application exposing REST endpoints

JSON responses for all API calls

The application is executed locally and accessed through a web browser using HTTP requests.

Implemented REST Endpoints

The following REST endpoints are implemented and operational:

/weddings Returns a list of weddings stored in the database.

/weddings/<wedding_id>/events Returns all events associated with the selected wedding.

/weddings/<wedding_id>/guests Returns all guests related to a specific wedding.

/weddings/<wedding_id>/attendance Displays attendance information for a wedding event, including guest names, roles, attendance status, and table assignments.

/weddings/<wedding_id>/rsvp Returns RSVP responses for guests for a selected event.

/availability/venue Checks venue availability for a given venue, date, and time interval and detects possible scheduling conflicts.

Demonstrated Functionalities

The prototype demonstrates the following key functionalities:

Retrieval of wedding data from the database

Display of attendance overview per event

Role-based guest participation (guest, best man)

Handling of optional attributes (e.g. table number)

Venue availability checking with time overlap detection

Venue Availability Logic

Venue availability is determined by checking existing bookings for a selected venue on a specific date.

Two scenarios are demonstrated:

Conflict case If an existing confirmed booking overlaps with the requested time interval, the venue is not available. The response returns "available": false and provides details about the conflicting booking.

Free case If no overlapping bookings exist, the venue is available. The response returns "available": true with an empty conflicts list.

This logic prevents double-booking of venues at the application level.

Prototype Evidence

The following screenshots are attached to this page as evidence of the working prototype:

Flask development server running locally

Overview of available REST endpoints

Wedding list endpoint response

Attendance overview endpoint response

Venue availability conflict example

Venue availability free example

These screenshots confirm the correct execution of the backend prototype and successful interaction with the database.

Conclusion

Phase P4 successfully demonstrates a working backend prototype for the Wedding Planner system. The implementation validates the database design from previous phases and confirms the correct behavior of core system functionalities through RESTful API endpoints.

The prototype provides a solid foundation for further development and potential frontend integration.