You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.

76 lines
3.1 KiB

## CRUD Master
### Instructions
APIs are a very common and convenient way to deploy services in a modular way.
In this exercise we will create a simple API infrastructure, having an API gateway connected with two other APIs.
Those two APIs will in turn get data from two distinct databases.
The communication between APIs will be done by using HTTP and message queuing systems.
All those services will be in turn encapsulated in different virtual machines.
#### General overview
We will setup an e-commerce system, where one API (`inventory`) will take track of the orders and another one (`billing`) will process the payments.
The API gateway will communicate in HTTP with `inventory` and using RabbitMQ for `billing`.
#### API 1: Inventory
##### Definition of the API
This API will be a CRUD (Create, Read, Update, Delete) RESTful API.
It will interact with a PostgreSQL database.
It will provide information about the products presents in the inventory of the store and allow users to do basic operations on it.
A common way to do so is to use Express (TODO add a link?) which is a popular Node.js web framework.
We will couple it with Sequelize (TODO add a link?), an ORM (TODO add a link?) which will abstract and simplify the interactions between our API and the database.
Here are the entrypoints with the possible HTTP requests:
- `/products`: GET, POST, DELETE
- `/products/:id`: GET, PUT, DELETE
- `/products/available`: GET
Some details about each one of them:
- `GET /products` retrieve all the products.
- `GET /products?title=[name]` retrieve all the products with `name` in the title.
- `POST /products` create a new product entry.
- `DELETE /products` delete all products in the database.
- `GET /products/:id` retrieve a single product by `id`.
- `PUT /products/:id` update a single product by `id`.
- `DELETE /products/:id` delete a single product by `id`.
- `GET /products/available` retrieve all available the products.
The API should work on `http://localhost:8080/`.
(TODO add a link on how to setup it?)
##### Defining the Database
The database will be a PostgreSQL and it will be called `products`.
Each product will have the following columns:
- `id`: autogenerated unique identifier.
- `title`: the title of the product.
- `description`: the description of the product.
- `available`: a boolean, it will be `true` if the product is available and `false` otherwise.
(TODO add link on how to setup it?)
##### Testing the API
In order to test the correctness of your API you should use Postman (TODO add a link?). You could create one or more tests for every entrypoint and then export the configuration so you will be able to reproduce the tests on different machines easily.
##### Documenting the API
Good documentation is a very critical feature of every API. By design the APIs are meant for others to use, so there have been very good efforts to create standard and easy to implement ways to document it.
As an introduction to the art of documenting you must SwaggerHub (TODO add a link?) with at least a meaningful description for each entrypoint. Feel free to implement any further and more complex feature.
#### API 2: Billing
#### The API Gateway