Skip to content

IPW_IP 2324 1 A2

Jump to bottom
Luís Falcão edited this page Dec 4, 2023 · 2 revisions
Instituto Superior de Engenharia de Lisboa
Bachelor in Computer Science and Computer Engineering
Bachelor in Informatics, Networks and Telecommunications Engineering
Internet Programming/Introduction to Web Programming
Winter Semester of 2023/2024 – 2nd practical assignment - SECA - Part1

Delivery

Due date for this assignment: 26/11/2023-23h59 03/12/2023-23h59

Delivery method

The delivery method is done through Github Classroom, using the invitation links below. Following the corresponding link, login with your github user and select your student id to make the correspondence between them and create a new group or join an existing one. If you create a new repository, the repository name should be: <LEIC|LEIRT>2324i-<COURSE><CLASS>-<GROUP_NUMBER>. For example:

  • Group 2 for class LEIC31D from IPW course, should name the repository: LEIC2324i-IPW31D-G02
  • Group 1 for class LEIRT51D from PI course LEIRT2324i-PI51D-G01.

These are the Github Classroom Invitation links:

  • LEIC (2 pools, depending on 1s assignment being delivered within its schedule or not)

  • LEIRT

The assignment should be delivered in this repository, by creating a tag called SECA-P1. If you need to make some changes to the delivery, just create another tag named SECA-P1.1, SECA-P1.1, etc.

Introduction

The practical component evaluation for this course will be carried out based on the SECA (Shows & Events Chelas Application), to be developed throughout the semester. This application provides access, through a web interface (hypermedia), using the information provided by the Ticketmaster API. To enable access to this API, each student should use the Ticketmaster API key obtained for 1st assignment. That key must be included in the URL of each HTTP request. Note that this is a free API, and therefore it has rate limits for your requests. Be sure you understand and comply to these limits.

The development will be carried out incrementally, necessarily involving several code refactoring cycles and, therefore, it is essential that you make use of good programming practices in general, in order to reduce the effort associated with each cycle.

The development of the SECA application has 3 development cycles, phased in three parts (Part 1, Part 2 and Part 3). For each one, the deadline for delivering the solution will be defined, and it will be a non-negotiable requirement.

For each SECA functionality, the corresponding HTTP *endpoint- must be defined. The description of the application API (i.e all application endpoints) must appear on the repository in an OpenAPI file, named docs/seca-api-spec.json (or .yml). The repository must also contain the Postman collection export, with the requests that validate the API, in a file named docs/seca-api-test.json.

Summary of the artifacts to be submitted upon delivery:

  • OpenAPI/Swagger file with API documentation - docs/seca-api-spec.[yaml|json]
  • Postman API validation project for SECA application - docs/seca-api-test.json
  • Node.js SECA application files

Functional Requirements

Develop a web application that provides a web API that follows current principals of current Web the REST principles, with responses in JSON format and that supports the following features:

  • Get the list of the most popular events. The request has two optional parameters to limit the number of returned events - s (default 30) and the page number - p (default 1)
  • Search events by name. The request has two optional parameters to limit the number of returned events - s (default 30) and the page number - p (default 1)
  • Manage favorite events groups
    • Create group providing its name and description
    • Edit group by changing its name and description
    • List all groups
    • Delete a group
    • Get the details of a group, with its name and description and the list of its events with, for each event, its name, date, and, if available, its segment and genre.
    • Add a event to a group
    • Remove a event from a group
  • Create new user, given its username

For all group operations, 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, obtained from the crypto.randomUUID() method.

Non-Functional Requirements

The application must be developed with Node.js technology. To handle/receive HTTP requests, the express module must be used. To make HTTP requests, the fetch global function used.

The Ticketmaster API must be used to obtain data (query) about the events.

The data that is specific to the application, which can be created, altered and deleted, namely the entire group management, in this phase must be stored in memory.

Any of the base modules of Node.js can be used. In addition to these, in this 1st part of the work, only the following modules can be used:

  • express - Handling HTTP requests
  • debug – Debug messages
  • mocha and chai - Unit tests

Any other module you intend to use must be previously discussed and authorized by the corresponding teacher.

All PUT and POST requests must send their data (except unique resource identifiers) in the request body (body) and not in the query string. The body should be handled by builtin Express JSON middleware.

The server application must consist of at least 5 Node modules:

  • seca-server.mjs - file that constitutes the entry point to the server application
  • seca-web-api.mjs - implementation of the HTTP routes that make up the REST API of the web application
  • seca-services.mjs - implementation of the logic of each of the application's functionalities
  • tm-events-data.mjs - access to the Tickermaster API.
  • seca-data-mem.mjs - access to seca data (groups and users), in this version stored in memory .

The dependencies between these modules are as follows:

seca-server.mjs -> seca-web-api.mjs -> seca-services.mjs -> tm-events-data.mjs
-> seca-data-mem.mjs

The server application development methodology must be as follows and in this order:

  1. Design and document API routes (HTTP request type + URL+example response content) using OpenAPI/Swagger format.
  2. Create a collection in Postman (ex. SECA) to test API routes
  3. Implement the server application input module: seca-server.mjs. For this module it is not necessary to create unit tests, since it must not implement any logic other than receiving some arguments from the command line (configuration), registering routes and starting the web server. This module can be built as each route in seca-web-api.mjs is implemented.
  4. In the seca-web-api.mjs module implement the API routes one by one.
  • For each route implemented, use Postman tests to verify the correct functioning of that route.
  • Only move on to implementing the next route when the previous one is fully implemented and tested.
  • For each route, create a request in the Postman collection that validates it.
  • In this phase of the implementation of the module seca-web-api.mjs use local data (*mock- of seca-services.mjs), that is, testing must be performed without access to the Ticketmaster API or memory storage.
  1. Implement application services in seca-services.mjs module.
  • Follow an approach similar to the one used in seca-web-api.mjs in the development of the features of this module and respective unit tests.
  • seca-services.mjs module unit tests must be run without access to the Ticketmaster API (tm-events-data.mjs). That is, create a mock for that access.
  1. Implement data access modules:
  • tm-events-data.mjs - access to the Ticketmaster API.
  • seca-data-mem.mjs - access groups data.

Clone this wiki locally