Dans Spring with Kotorin --3. Omitting curly braces from function, API accessible par la méthode GET / POST / PUT / DELETE pour RestController Ajoutée.
Cependant, il n'y avait pas de directive particulière sur la façon de l'ajouter, et il a été ajouté de manière appropriée. Par conséquent, la seule directive était de rendre l'API à publier facile à comprendre, et chaque fonction définie comme suit était nommée et définie.
@GetMapping(value = ["/display"])
fun getMessages() : List<Message> {
Par conséquent, je voudrais le changer en une conception ** de type API REST **.
Spring Dependencies
Ici, nous ne considérerons pas encore strictement la conception de l'API, mais nous ne considérerons que la politique minimale.
La définition originale était de déterminer le chemin racine en annotant la classe et de déterminer l'URI d'accès pour chaque fonction. Le nom était une notation verbale pour une utilisation facile.
@RequestMapping("/simple")
class SimpleController {
@GetMapping(value = ["/display"])
fun getMessages() : List<Message> {
Par conséquent, en réalité, l'accès était le suivant, et c'était un accès semblable à un verbe.
http://xxx/simple/display
Ce que je voulais * afficher * dans ce processus était ** messages **. Par conséquent, changez l'accès de ce qui précède à l'accès avec la nomenclature prévue pour * messages * comme suit.
http://xxx/messages
@RequestMapping("/messages")
class SimpleController {
@GetMapping()
fun getMessages() : List<Message> {
L'URL d'accès décrite dans la fonction a disparu, ce qui sera expliqué ci-après.
J'ai essayé d'accéder par nomenclature avec l'URI d'accès expliqué ci-dessus. Assurez-vous que l'opération CRUD (CREATE / READ / UPDATE / DELETE) sur le nom d'accès est représentée par la méthode HTTP (GET / POST / PUT / DELETE). Par conséquent, vous n'avez plus besoin d'un URI d'accès par fonction tel que défini précédemment.
La relation entre les méthodes HTTP et les opérations CRUD est la suivante.
| Méthode HTTP | Fonctionnement CRUD | sens |
|---|---|---|
| GET | READ | Avoir |
| POST | CREATE | enregistrement |
| PUT | UPDATE | mise à jour |
| DELETE | DELETE | Effacer |
POST et PUT sont des méthodes HTTP utilisées pour créer et mettre à jour des états. Alors pourquoi POST a-t-il été CREATE et PUT UPDATE?
La raison est l'équivalence des méthodes HTTP.
L'égalité est une propriété qui donne le même résultat même si elle est réexécutée.
L'égalité de la méthode HTTP est la suivante.
| Méthode HTTP | Égalité |
|---|---|
| GET | 冪 etc. |
| POST | Non-mort, etc. |
| PUT | 冪 etc. |
| DELETE | 冪 etc. |
Imaginez le processus d'inscription. Si vous exécutez la même instruction plusieurs fois, le même enregistrement sera créé plusieurs fois. Ce n'est pas un fantôme. D'autre part, dans le processus de mise à jour, le résultat ne change pas même si la même instruction est exécutée plusieurs fois. C'est un 冪 etc.
En pensant de cette manière, il s'avère que ** POST = CREATE = non- 冪 etc. ** / ** PUT = UPDATE = 冪 etc. ** est approprié.
Sur la base de ce qui précède, il a été modifié comme suit.
--Accès féminin
Avant correction
@RequestMapping("/simple")
class SimpleController {
@PutMapping(value = ["/insert"])
fun insertMessage(@RequestBody message: Message) : Message {}
@PostMapping(value = ["/update"])
fun updateMessage(@RequestBody message: Message) : Message {}
modifié
@RequestMapping("/messages")
class SimpleController {
@PostMapping
fun insertMessage(@RequestBody message: Message) : Message {}
@PutMapping
fun updateMessage(@RequestBody message: Message) : Message {}
Cette fois, j'ai abordé «facile» la conception de l'API REST. À proprement parler, cela ne suffit pas. Il y a encore de nombreux éléments à prendre en compte, tels que la gestion des versions d'API, la superposition, la représentation de la collection et le code d'état.
Pour le moment, cette fois je l'ai traité comme la chose minimale à penser et faire simplement.
À l'avenir, j'aimerais reconsidérer la conception des API en parlant de la conception des microservices.
Recommended Posts