---
# System prepended metadata

title: Rest API with Spring boot (part 2)

---

# ATLAS - Rest API with Spring boot (part 2)

## Context
See [part 1](https://hackmd.io/OAcft3gBT0SkV-SF__rGeg) for details on the context.

## Design and implement a Rest API
Thanks to your Spring boot project you can know start to expose Web services following some Rest architectural principles.

### Business entites
A business entity is a representation in the form of objects of some real life objects (orders, invoices, people, events, products and so on). The type of object we design and implement in our applications depends on the business context of the users of the applications.

ATLAS is a project in order to manage data related to the business entities here after.

Implement classes to meet the requirements, these classes should be in one specific package.

#### Country
- ISO code 2
- ISO code 3
- Name
- Population
- Area (in km²)
- Official language

#### Continent
- Name
- Area (in km²)

#### Capital
- Name
- Population
- Area (in km²)

In every application we need to be able to uniquely identify each entity: each country, each continent and each capital in our application. To identify each instance, each business entity must have a specific property, an identifier of type `UUID` (could be another type of data.)

> Choose judiciously the Java types, and obey to the "Javabean naming conventions" for the business entity classes.

### In memory database
At this stage, you do not have a database to store the created entities. You have to design and implement a **simple** in-memory database.

Implement a `Database` class in a separate package with static methods, methods specific to each type of entity, entities are saved in a dedicated `Map` data structure with the identifier as the key and the instances as the values. Do not implement the methods all at once, implement them only when needed.

> Note that as it is an in-memory database, all the data will be lost each time you stop and/or restart your Spring boot application.

### Request mappings and rest controllers
Design and implement the routes (or endpoints) here after in order to create an instance of each type of entity and to retrieve one instance thanks to its identifier. Routes are declared in rest controllers. The practice is to have a controller for each type of entities.

> Pay attention to the verbs, to the returned HTTP success status in the response, try to identify and specify the correct HTTP status (200, 201...) depending on the context. And don't forget to obey to the Rest naming conventions.

#### Create a resource
- Expose a route in order to create an entity. The client sends a request specifying the route (verb + path) and a JSON in the body of the request. The controller (server component) receives a Java object representing the data in the JSON, this object has to be saved in the in-memory database

#### Retrieve a resource thanks to its identifier
- Expose a route in order to retrieve an existing entity thanks to its identifier. The client sends a request specifying the route (verb + path) with the identifier as a "path variable". The controller receives the identifier in the path and searches for the corresponding entity in the in-memory database thanks to the identifier, then returns the entity. The client receives an HTTP response with the entity as a JSON in the response body

### What you should have learned?
At this stage, each team member should be able to answer to these questions:
- What are the "Javabean naming convention" and why we do need naming conventions in our context (business entities)?
- What is a rest controller?
- What is a request mapping?
- What is an annotation?
- What is a path variable?