In Spring with Kotorin --3. Auslassen von geschweiften Klammern aus der Funktion, API, auf die mit der GET / POST / PUT / DELETE-Methode für RestController zugegriffen werden kann Hinzugefügt.
Es gab jedoch keine spezielle Richtlinie zum Hinzufügen und sie wurde entsprechend hinzugefügt. Daher bestand die einzige Richtlinie darin, die zu veröffentlichende API leicht verständlich zu machen, und jede wie folgt definierte Funktion erhielt einen Namen und wurde definiert.
@GetMapping(value = ["/display"])
fun getMessages() : List<Message> {
Daher möchte ich es in ein ** REST API-ähnliches ** Design ändern.
Spring Dependencies
Hier werden wir das API-Design noch nicht streng betrachten, sondern nur die Mindestrichtlinie.
Die ursprüngliche Definition bestand darin, den Stammpfad durch Annotieren der Klasse und den Zugriffs-URI für jede Funktion zu bestimmen. Der Name dort war eine Verbnotation für einfache Bedienung.
@RequestMapping("/simple")
class SimpleController {
@GetMapping(value = ["/display"])
fun getMessages() : List<Message> {
Daher war der Zugriff in Wirklichkeit wie folgt und es war ein verbartiger Zugriff.
http://xxx/simple/display
Was ich in diesem Prozess * anzeigen * wollte, waren ** Nachrichten **. Ändern Sie daher den Zugriff von oben auf den Zugriff mit der vorgesehenen Nomenklatur für * Nachrichten *, wie unten gezeigt.
http://xxx/messages
@RequestMapping("/messages")
class SimpleController {
@GetMapping()
fun getMessages() : List<Message> {
Die in der Funktion beschriebene Zugriffs-URL ist nicht mehr vorhanden. Dies wird im Folgenden erläutert.
Geändert zum Zugriff nach Nomenklatur mit der oben erläuterten Zugriffs-URI. Stellen Sie sicher, dass die CRUD-Operation (CREATE / READ / UPDATE / DELETE) für das Nomen, auf das zugegriffen wird, durch die HTTP-Methode (GET / POST / PUT / DELETE) dargestellt wird. Infolgedessen benötigen Sie keinen Funktions-URI mehr pro Funktion, wie zuvor definiert.
Die Beziehung zwischen HTTP-Methoden und CRUD-Operationen ist wie folgt.
| HTTP-Methode | CRUD-Betrieb | Bedeutung |
|---|---|---|
| GET | READ | Erhalten |
| POST | CREATE | Anmeldung |
| PUT | UPDATE | aktualisieren |
| DELETE | DELETE | Löschen |
Sowohl POST als auch PUT sind HTTP-Methoden zum Erstellen und Aktualisieren von Status. Warum war POST CREATE und PUT UPDATE?
Der Grund ist die Gleichwertigkeit der HTTP-Methoden.
Gleichheit ist eine Eigenschaft, die das gleiche Ergebnis liefert, selbst wenn sie erneut ausgeführt wird.
Die Gleichheit der HTTP-Methode ist wie folgt.
| HTTP-Methode | Gleichberechtigung |
|---|---|
| GET | 冪 etc. |
| POST | Nicht-Tod usw. |
| PUT | 冪 etc. |
| DELETE | 冪 etc. |
Stellen Sie sich den Registrierungsprozess vor. Wenn Sie dieselbe Anweisung mehrmals ausführen, wird derselbe Datensatz mehrmals erstellt. Es ist kein Geist. Andererseits ändert sich beim Aktualisierungsprozess das Ergebnis nicht, selbst wenn derselbe Befehl mehrmals ausgeführt wird. Es ist ein 冪 etc.
Wenn man so denkt, stellt sich heraus, dass ** POST = CREATE = non- 冪 usw. ** / ** PUT = UPDATE = 冪 usw. ** angemessen ist.
Basierend auf dem Obigen wurde es wie folgt modifiziert.
Vor der Korrektur
@RequestMapping("/simple")
class SimpleController {
@PutMapping(value = ["/insert"])
fun insertMessage(@RequestBody message: Message) : Message {}
@PostMapping(value = ["/update"])
fun updateMessage(@RequestBody message: Message) : Message {}
Überarbeitet
@RequestMapping("/messages")
class SimpleController {
@PostMapping
fun insertMessage(@RequestBody message: Message) : Message {}
@PutMapping
fun updateMessage(@RequestBody message: Message) : Message {}
Dieses Mal habe ich "einfach" über das Design der REST-API gesprochen. Genau genommen reicht das nicht aus. Es gibt noch viele Dinge zu beachten, wie API-Versionierung, Layering, Sammlungsdarstellung und Statuscode.
Dieses Mal habe ich es vorerst als das Minimum angesehen, einfach zu denken und zu machen.
In Zukunft möchte ich das API-Design überdenken, wenn ich über das Design von Microservices spreche.
Recommended Posts