Spring Boot REST-Pfad-Zuordnung

Ich bin gerade am überlegen, was ist die beste Praxis zu erstellen-PFAD-Zuordnung für rest-Dienst.
Sagen wir mal wir haben folgenden Pfade:

/users POST
/users/1 PATCH, GET
/users/1/contacts GET, POST
/users/1/contacts/1 GET, PATCH

Die Frage ist - was ist die best practice, die Erstellung von Controllern.
Zum Beispiel haben wir UserController, wo wir technisch könnten alle diese Zuordnungen. Oder - wir sollten erstellen Sie separate Controller (UserController,
ContactsController).
f.e UserController unten, wenn wir alles unter.

@RequestMapping("users")
@RestController
public class UserController {

    @RequestMapping(method = RequestMethod.POST)
    public ResponseEntity<Void> createUser() {}

    @RequestMapping(method = RequestMethod.GET)
    public User getUser() {}

    @RequestMapping(value = "{id}/contacts", method = RequestMethod.GET)
    public List<Contact> getContacts() {}

    @RequestMapping(value = "{id}/contacts", method = RequestMethod.POST)
    public ResponseEntity<Void> createContact() {}

    .....
}

Und wenn wir getrennte Steuerungen, wie Wege organisiert werden sollte dann werden?
Wahrscheinlich ist es eine dumme Frage, aber ich werde froh sein, wenn jemand Erfahrungen zu teilen.

Ich bin ein fan für separaten regler so entfernen Sie die Kopplung zwischen Benutzer und Kontakte (zum Beispiel) - was ist, wenn Sie später verwenden möchten Kontakte in einem separaten Kontext? (d.h. unabhängig von der Benutzer, dem Sie gehören)

InformationsquelleAutor comprex | 2016-10-11

Lässt vermuten, dass die Anzahl der Einheiten, die im Zusammenhang mit Benutzer-wird sich in Zukunft noch verstärken. So ist es offensichtlich, dass es besser ist, um es zu teilen nach Entitäten:

UserController -> UserService -> UserRepository,

ContactController -> ContactService -> ContactRepository,

FriendshipController -> FriendshipService -> FriendshipRepository

Aus meiner Erfahrung, User-Controller

@RestController
@RequestMapping("/user")
public class UserController extends AbstractController {

...

   @RequestMapping(method = RequestMethod.POST)
   public ResponseEntity<?> createUser(@RequestHeader("X-Auth-Token") Optional<String> @RequestBody User user) {

...

   @RequestMapping(method = RequestMethod.GET)
   public ResponseEntity<?> listUsers(@RequestHeader("X-Auth-Token") Optional<String> authToken) {
...

Bezug auf Benutzer-Bereich Freundschaft controller:

@RestController
@RequestMapping("/user/{id}")
public class FriendshipController extends AbstractController {

...

@RequestMapping(value = "/friendship/code", method = RequestMethod.POST)
    public ResponseEntity<?> generateCodeForUser(@PathVariable("id") long id) {

...

 @RequestMapping(value = "/friendship/code", method = RequestMethod.GET)
    public ResponseEntity<?> retrieveCodeForUser(@PathVariable("id") long id) {

...

Nicht sicher, es ist axiom, sondern mir helfen, organisieren meine code.

Ich würde sogar vorschlagen, dass die Freundschaft controller mapping sollte @RequestMapping("/user/{id}/friendship") und dann werden alle anderen Zuordnungen sind vereinfacht in /code

InformationsquelleAutor Sergii Getman

1

Ich bin ein fan für separaten regler so entfernen Sie die Kopplung zwischen Users und Contacts (zum Beispiel) - was ist, wenn Sie später verwenden möchten Contacts in einem separaten Kontext? (d.h. unabhängig von der User Sie gehören)

Wenn Sie getrennt sind, können die Wege Aussehen würde, sehr ähnlich zu dem, was Sie haben:

Benutzer
```
/users GET, POST
/users/{user-id} PATCH, GET
```
Kontakte
```
/contacts GET, POST
/contacts/{contact-id} GET, PATCH
```
Wenn es eine Abhängigkeit zwischen Contacts und Users (und in diesem Fall, es sieht aus wie es eine ist), können Sie es wie folgt:
```
/contacts/for-user/{user-id} GET, POST
/contacts/for-user/{user-id}/{contact-id} GET, PATCH
```
Dadurch können Sie Kontakte hinzufügen, um andere Dinge (nicht nur Benutzer) und Benutzer auf andere Kontexte (unabhängig von deren Kontakte)

Angenommen, die Benutzer einer Kaffeemaschine
```
/coffee-maker/users GET
```
Oder wenn die Kaffeemaschine ausfällt, wen wir Kontaktieren Sie für eine Reparatur?
```
/coffee-maker/contacts GET
```
Wohl einen Kontakt für eine Kaffeemaschine Reparatur ist auch ein User (aber nicht müssen),

Eine weitere Sache, können Sie es umdrehen und sagen, dass ein Kontakt für ein Gerät (z.B. eine Kaffeemaschine)
```
  /contact/for-appliance/{appliance-id} GET
```
Mein Punkt ist, dass, wenn Sie entkoppeln die Kontakte der Nutzer, die Sie zuweisen können, Kontakte zu anderen Einrichtungen statt zwingen, die Beziehung zu User -> Contacts - es sei denn, natürlich, Sie wollen nicht entkoppelt, da der business-Regeln oder irgendeinem Grund

In jedem Fall, Bedenken Sie, dass es gibt viele Möglichkeiten, das mapping

InformationsquelleAutor blurfus

Schreibe einen Kommentar

Du musst angemeldet sein, um einen Kommentar abzugeben.