-
Notifications
You must be signed in to change notification settings - Fork 5
Workshop #3: Enhancing API layer
Workshop #3 is about enhancing the API layer - not only the REST one but the API contract in general (e.g. between modules communicating with each other). Therefore, you can find topics such as:
- HTTP basics (methods, status codes, etc.)
- REST API conventions
- Swagger definitions
- Java components visibility
- SOLID
This workshop
You can find the source code that represents the status of the project after this workshop - TBD
Let's recollect what the HTTP is and what is the proper way to use it in terms of building efficient and readable REST APIs :)
HTTP stands for Hyper Text Transfer Protocol. This protocol is used to transfer data (HTML documents, CSS/JS files, JSON data, etc.) over the Internet between clients and servers via HTTP requests and HTTP responses.
We can distinguish 5 mostly used HTTP methods: GET, POST, PUT, DELETE, PATCH (full list available on https://developer.mozilla.org/en-US/docs/Web/HTTP/Methods site).
| HTTP Method | Description | Safe | Idempotent | Has request body | Has response body |
|---|---|---|---|---|---|
| GET | Read a resource | Yes | Yes | Optional | Yes |
| POST | Create a new resource | No | No | Yes | Yes |
| PUT | Update a resource | No | Yes | Yes | Yes |
| DELETE | Delete a resource | No | Yes | Optional | Optional |
| PATCH | Update partially a resource | No | No | Yes | Yes |
HTTP response status codes indicate the result of the processed HTTP request. They are grouped into five classes:
-
1xx: Informational responses -
2xx: Successful responses -
3xx: Redirection responses -
4xx: Client error responses -
5xx: Server error responses
A full list of HTTP status codes can be found at https://developer.mozilla.org/en-US/docs/Web/HTTP/Status site.
Let's take a sample GET request:
https://api.example.com:3000/shop/v1/items?category=fruits
and decompose it into the parts:
-
http://- request protocol (http or https) -
api.example.com- host -
3000- port (forhttpdefault port is80and forhttpsis443) -
/shop/v1/items- request URI -
?category=fruits- query params
Additionally, an HTTP request can contain:
- request body (it can be in plain text, x-www-form-urlencoded, binary, JSON, etc.)
- request headers
Each HTTP response contains:
- response headers
- response body
- HTTP status code
According to Red Hat, REST API (also known as RESTful API) is an application programming interface (API or web API) that conforms to the constraints of REST architectural style and allows for interaction with RESTful web services. REST stands for representational state transfer and was created by computer scientist Roy Fielding.
An API is a set of definitions and protocols for building and integrating application software. It’s sometimes referred to as a contract between an information provider and its consumer.
Let's see what rules we should follow to build an understandable and efficient REST API.
You should NOT use any verbs in the request URI in a designed REST API. This should be done by using the proper HTTP method (see HTTP methods table for more details).
Bad practice:
GET http://api.example.com/shop/v1/list-items
POST http://api.example.com/shop/v1/items/create
Good practice:
GET http://api.example.com/shop/v1/items
POST http://api.example.com/shop/v1/items
The request URI should always describe the resource which you will manage (the HTTP method indicates in which way). It is also important to design proper resource nesting.
Bad practice:
GET http://api.example.com/shop/v1/items/by-id/1
GET http://api.example.com/shop/v1/items/employees
Good practice:
GET http://api.example.com/shop/v1/items/1
GET http://api.example.com/shop/v1/basket/items
You should use kebab-case naming convention while building request URIs to keep good readability.
Bad practice:
GET http://api.example.com/shop/v1/shopEmployees
GET http://api.example.com/shop/v1/shop_employees
Good practice:
GET http://api.example.com/shop/v1/shop-employees
You should always return proper status code that informs about the actual status (e.g. if request has been processed successfully or client provided invalid data in request body). You can find a full list of status codes with detailed descriptions at https://developer.mozilla.org/en-US/docs/Web/HTTP/Status site.
Now let's dig into code and see how we can write readable and easily extensible REST APIs in Spring Boot.
This part will available after workshops 📽
This part will available after workshops 📽
This part will available after workshops 📽
This part will available after workshops 📽
Apart from the REST API layer, we should also take care of rest of the project components to make the whole system scalable and maintainable. Therefore, one of the ways is to properly group code/components by their functionality into so-called domains.
This part will available after workshops 📽
This part will available after workshops 📽
This part will available after workshops 📽