Project overview

In group of three or four students, you have to create a REST/RESTful API of your choice in Node.JS. You are responsible of choosing the kind of APIs you wish to develop, writing the specification, and developing and testing the API through a top-down approach. Some ideas of APIs: code snippet retrieval, cooking recipes, playlist management, etc. Be original.

Steps for developping the API

To develop the API, you will have to:

Specify the system and analyse it: The underlying part of the API is to specify your domain, in terms of a data model/UML class diagram, which must conform to the system specification. This is usually done during the analysis phase of the project.

Formalise the system using OpenAPI and Swagger: an OpenAPI specification consists in defining all the possible HTTP requests that can be done to interrogate the API, query some information, and/or update it.

Implement the server: The server must be implemented in Node.JS. It can be either done manually and must conform to the OpenAPI specification, or generated using the Swagger tools, as it will be seen during the lab sessions. However, Swagger will only generate the skeleton of the server (handling the HTTP requests), and the logic must still be implemented by hand.

Manage data: Data must be delivered by the API. You can use the database management system of your choice, as long as it is easy to install and to deploy in a docker image (see below).

Test the API and provide analysis reports: You will have to specify a test suite and write the different tests of your server. You will focus on structural/functional tests, and you will evaluate the completness of the test suite using different metrics of code coverage/mutation testing. SonarQube will be used to generate quality analysis reports.

Build a Node.JS package/docker images: The API implementation must be deployed as a Node.JS package and provided docker images to be able to execute it.

Automate the full process: You will implement a CI/CD pipeline on Githab to support the automatic building, test regression, version management, and quality analysis reports.

Provide a user guide: The user guide should explain how the API can be used, which are the kinds of requests that could be done.

Provide developer artifacts at the destination of developers/maintainers/teacher: : Such artifacts may include changelogs, technical debts, styling conventions applied, Architectural Decision Request, etc.

Evaluation criteria

Different evaluation criteria will be taken into considerations for evaluating your API, among which:

API complexity : The API is complex enough to guarantee that all parts of the course are covered, but not too complex to be done in a reasonable amount of time, according to the given calendar.

Quality of the artifacts/implementation : The produced artifacts (being code, test suites, analysis reports, etc.) must be of high quality.

Consistency accross the different phases/artifacts : The consistency accross the different phases/artifacts is an important criteria of evaluation. Example of inconsistencies that can be observed: some HTTP routes implemented in the server are not defined as such in the OpenAPI specification. In case you know such inconsistencies exists but would not have time to fix them on time, please mention it as technical debt in the developer artifacts.

Respect of the instructions/deadlines/involvment of the group members : The respect of the given instructions and submitting the different artifacts when required will be taken into consideration in the final grade.

Submission process

The project development follows an incremental top-down approach, from system specification to analysis, design, implementation, and test. Different deadlines are defined below and must be handed-in at the given deadline. Please note that artifacts submitted at a specific deadline might be partial (e.g., only half of the system specification is covered by the implementation when handed-in), yet, they must be functional (e.g., the code of the server can be executed without errors). The artifacts submitted at a specific deadline are not frozen and can be further updated. The main reason behind the incremental approach is that some lectures and lab sessions will require specific parts of the project to be done.

You are responsible of honoring the different deadlines. We will not send reminders systematically. Failing to honor a deadline will affect the grade negatively.

The first submission consists in creating the groups. Each group consists of three students. The groups must be defined before October, 18 at 5pm using the following Google form. Once the groups are defined, a Gitlab project will be created for each group. All the other assignments must be exclusively handed-in on Gitlab (no e-mails).

Important Dates

The table below details the different assignments, the platform to hand-in, and the deadlines. Please note that each deadline is set at 5pm (no 11.59pm submission).

| Name of the artifact | Format | Hand-in platform | Deadline | |-----------------------------------|---------------------------|----------------------------------------------------|----------------| | Group creation | - | Google form | Oct 18 at 5pm | | System specification and analysis | Markdown | Gitlab | Nov. 8 at 5pm | | OpenAPI specification | YAML specification | Gitlab | Nov. 15 at 5pm | | Server implementation (partial) | code | Gitlab + Gitlab registry | Nov. 22 at 5pm | | Test suites | code | Gitlab | Nov. 29 at 5pm | | Pipeline | YAML specification | Gitlab | Dec. 6 at 5pm | | SonarQube report | PDF files | Gitlab | Dec. 6 at 5pm | | Docker image | Docker configuration file | Gitlab | Dec. 13 at 5pm | | Final implementation | code | Gitlab | Dec. 20 at 5pm | | User/Developer guides | Markdown | Gitlab | Dec. 20 at 5pm | | Implementation lowcode variant | TBD | TBD | (TBD) |