Project: Tickets API
During the course, we developed the API for product resources. In the real world, every product will have some bugs or issues. These issues/bugs have their own lifecycle, which can be represented by a ticket API.
Let’s define the ticket resource our server will work with and what it contains.
In our example scenario, a product resource represents a master list of products. Each product has an id
, version
, name
, and description
uniquely identified by the id
. Each product can have many issues/bugs associated with it. A ticket resource can be used to represent each issue/bug. Each ticket will have an id
, product_id
, summary
, and description
.
The below diagram shows the relationship between a product and a ticket. Please note that the relationship is one-to-many, i.e., each product can have zero or more issues/bugs (tickets) associated with it.
In this project, your task is to develop an API that provides REST-based operations for the ticket resource of a specific product identified by product_id
.
The project has been divided into multiple tasks, each corresponding to a lesson in the course. Each task builds upon the previous one.
The task details are as follows:
The operations for the tickets resource can also be developed using the product_id
in the URL, i.e., /api/products/{product_id}/tickets
.
This is a requirement that, we have to design the solution based on the problem statement and context.
When we use product_id
in the URL, it connects products and tickets at the endpoint level, whereas when product_id
isn’t used, the ticket is connected with the product at the data level.
What this practically means is that when product_id
is used, the validation occurs at the URL level and can be performed using interceptors. On the other hand, if product_id
isn’t used, the POST/PUT
data will be passed to the method, which will need to perform the validation.
Note: The implementation of the
product_id
based API is left as an exercise for the learner.