In Spring with Kotorin --3. Omitting curly braces from function, API that can be accessed by GET / POST / PUT / DELETE method for RestController Added.
However, there was no particular guideline on how to add it, and it was added appropriately. Therefore, only the guideline to make the API to be published easy to understand was defined by giving a name to each function defined as follows.
@GetMapping(value = ["/display"])
fun getMessages() : List<Message> {
Therefore, I would like to change it to a ** REST API-like ** design.
Spring Dependencies
Here, we will not consider the API design strictly yet, but consider only the minimum policy.
-** Access with noun ** --Not a verb
In the original definition, the root path was determined by annotation to the class, and the access URI was determined for each function. The name there was a verb notation for easy operation.
@RequestMapping("/simple")
class SimpleController {
@GetMapping(value = ["/display"])
fun getMessages() : List<Message> {
Therefore, in reality, the access was as follows, and the access was verb-like.
http://xxx/simple/display
What I wanted to * display * in this process was ** messages **. Therefore, change the access from the above to the access with the intended noun that targets * messages * as shown below.
http://xxx/messages
@RequestMapping("/messages")
class SimpleController {
@GetMapping()
fun getMessages() : List<Message> {
The access URL described in the function is gone, which will be explained next.
I tried to access by noun with the access URI explained above. Make sure that the CRUD operations (CREATE / READ / UPDATE / DELETE) on the noun you access are represented by HTTP methods (GET / POST / PUT / DELETE). As a result, you no longer need a per-function access URI as defined earlier.
The relationship between HTTP methods and CRUD operations is as follows.
| HTTP method | CRUD operation | meaning |
|---|---|---|
| GET | READ | Get |
| POST | CREATE | Registration |
| PUT | UPDATE | update |
| DELETE | DELETE | Delete |
Both POST and PUT are HTTP methods used to create and update states. So why did POST be CREATE and PUT UPDATE?
The reason is the idempotency of HTTP methods.
Idempotence is a property that gives the same result even if it is re-executed.
The idempotency of the HTTP method is as follows.
| HTTP method | Idempotent |
|---|---|
| GET | Idempotent |
| POST | Non-idempotent |
| PUT | Idempotent |
| DELETE | Idempotent |
Imagine the registration process. If you execute the same instruction multiple times, you will end up with the same record multiple times. It is not idempotent. On the other hand, in the update process, the result does not change even if the same instruction is executed multiple times. Idempotent.
Thinking this way, ** POST = CREATE = non-idempotent ** / ** PUT = UPDATE = idempotent ** is appropriate.
Based on the above, it has been modified as follows.
--Noun access --CRUD processing with HTTP method --Registration process considering idempotency
Before correction
@RequestMapping("/simple")
class SimpleController {
@PutMapping(value = ["/insert"])
fun insertMessage(@RequestBody message: Message) : Message {}
@PostMapping(value = ["/update"])
fun updateMessage(@RequestBody message: Message) : Message {}
Revised
@RequestMapping("/messages")
class SimpleController {
@PostMapping
fun insertMessage(@RequestBody message: Message) : Message {}
@PutMapping
fun updateMessage(@RequestBody message: Message) : Message {}
This time, I touched on "easy" about the design of REST API. Strictly speaking, this is not enough. There are still many things to consider, such as API versioning, layering, collection representations and status codes.
For the time being, this time I treated it as the minimum thing to think simply and make.
In the future, I would like to reconsider API design when talking about the design of Microservices.
Recommended Posts