Phase 1

Phase 1

Goals

The Software Laboratory project consists of the analysis, design and implementation of an information system to manage padel courts. Its development is divided into 4 phases, with incremental requirements published before the beginning of each phase.

Domain

• A user is characterized by a unique number (uid), a name and a unique email.

• A club is characterized by a unique number (cid), a unique name and is associated to a user (owner).

• A court is characterized by a unique number (crid), a name and is associated to a club.

• A rental is characterized by a unique number (rid), a date, a duration in hours and is associate to a user and a court

NOTE: All courts are avaliable 24 hours

Phase 1 requirements

Development of the backend service. The service must expose an HTTP API to frontend client applications. The API should provide the following functionalities:

User Management

• Create a new user, given the following parameters:

  • name - the user's name
  • email - the user's unique email.

  Returns the user's token and the user’s identifier (uid).

• Get the details of a user.

Club Management

• Create a club, given the following parameters:

  • name - the club name

  Returns the club identifier (cid).

• Get the details of the club.

• Get a list with the clubs

Court Management

• Creates a new court, given the following parameters:

  • name- court name
  • cid - club identifier

  Returns the court identifier (crid).

• Get the detailed information of a court.

• Get a list with the courts given the club identifier.

Rental Management

• Create a rental, given the following parameters:

  • cid - club identifier
  • crid - court identifier
  • date - rental date with initial hour
  • duration - duration in hours

  Returns the rental identifier (rid).

• Get the detailed information of a rental.

• Get a list with the rentals, given the following parameters:

  • cid - club identifier
  • crid - court identifier
  • date - date (Optional)

• Get a list with the rentals of a user

• Get a list with the avaliable hours to rent a court of a club, given the following parameters:

  • cid - club identifier
  • crid - court identifier
  • date - date

Paging

All Web API GET operations that return a sequence should support paging, i.e., the ability to return a subsequence from the overall sequence. This paging is defined by two parameters:

• limit - length of the subsequence to return.
• skip - start position of the subsequence to return.

For example, the request GET /rentals?skip=6&limit=3 returns the rentals subsequence starting at the seventh rental and ending on the ninth rental.

NOTE: For all operations that require authentication, a user token must be sent in the Authorization header using a Bearer Token. This token is generated at user creation, and consists of a UUID string (you can use Uuid class from kotlin.uuid package for ID generation). Students should determine which functionalities require authentication and authorization. For example, only authenticated users can create resources, and only the club owner can add courts.

Non-functional requirements

The backend must be developed with Kotlin technology. To handle/receive HTTP requests, the HTTP4K library must be used. The body serialization/deserialization should be done using the kotlinx.serialization library- You can see a functional usage example of both libraries here. The data that are specific to the application, which can be created, altered and deleted must be stored in a Postgres database. Tests run using data stored in memory, not the database. The following non-functional requirements will be highly valued.

• Readability.
• Testability, including on machines not belonging to the development team.

NOTE: Tests are mandatory

Guidelines about design and implementation

At the beginning of the development, the server application should store the data in memory and the solution should start with 4 files:

• courtsServer.kt - file that constitutes the entry point to the server application
• courtsWebApi.kt - implementation of the HTTP routes that make up the REST API of the web application
• courtsServices.kt - implementation of the logic of each of the application's functionalities
• courtsDataMem.kt - access to data, stored in memory.

The dependencies between these are as follows:

courtsServer.kt -> courtsWebApi.kt -> courtsServices.kt -> courtsDataMem.kt

During the development of this phase other files can (and should) be created, in order to structure the code in a more logical and readable form. Solutions with large code files are highly discouraged.

Report and HTTP API Documentation

• The phase 1 delivery must include a technical report, in the docs repository folder, using the following template.

• It also has to include the HTTP API documentation required for a frontend client application to use this API. This documentation should not include any information about the internal backend implementation. Students are encoraged to follow OpenAPI specification.

Delivery date

The project must be delivered until 29 March (end of week 6), via the creation of a 0.1.0 tag on the GitHub repository.