Wie behandelt man, wenn REST-Ressourcen mit bereits vorhandenen Ressourcen verknüpft sind und diese erweitern?

Question

Ich baue eine REST-API, wo ich "Bücher" und "Benutzer" habe. Sie können nur ein einzigartiges Buch existieren. Obwohl ein Benutzer mehrere Bücher haben kann und verschiedene Benutzer das gleiche Buch haben können (oder sich auf dasselbe beziehen). Ein Benutzer kann einem Buch zusätzliche Informationen hinzufügen (z. B. Bewertung).

Meine Frage ist: Was ist eine korrekte Möglichkeit, die Ressourcen zuzuordnen, wenn Benutzer eine bereits vorhandene Buch-Ressource mit ihren eigenen Einstellungen "erweitern"?

Beispiel: Ein Erstbenutzer hat keine Bücher, aber sie können ein Buch erstellen. Wenn das Buch nicht existiert, wird es erstellt, wenn es existiert, erhalten sie Zugriff darauf. Sie können jedoch eigene private Zusatzinformationen hinzufügen.

Ist das ein richtiger Weg?

// Alle Bücher mit den grundlegenden erforderlichen Informationen können auf/Bücher zu erreichen /: id Beispiel:/Bücher/1 {

"id":1, 
"title":"The Empire", 
"description":"Description about the book", 
"serial":1234 

}

// Wenn ein Benutzer das schafft Buch "The Empire" (Serie: 1234) erweitern sie das bereits existierende Buch, haben aber zusätzliche Informationen hinzugefügt, so dass es sich eigentlich um eine neue URL handelt, die sich jedoch auf die Buch-ID bezieht.

Beispiel:/users/421/Bücher/1/

{ 
"id":1, 
"title":"The Empire", 
"description":"Description about the book", 
"serial":1234, 
"rating":5.5, 
    "note":"I liked the book but it was too long." 
} 

Oder auch:

{ 
"book":{ 
    id":1, 
    "title":"The Empire", 
    "description":"Description about the book", 
    "serial":1234, 
    } 
"rating":5.5, 
"note":"I liked the book but it was too long." 
} 

Oder sogar eine URL smth wie/users/421/Bücher/1/Einstellungen/

Answer 1

Ich würde empfehlen, die "Bewertungen" mit mehreren Eltern (Buch, Benutzer) zugeordnet werden und dann eine kanonische Ressource für den Revier haben w wie folgt:

Buch /books/{book-id}

{ 
"id":1, 
"title":"The Empire", 
"description":"Description about the book", 
"serial":1234 
} 

Bewertungen eines Buches /books/{book-id}/reviews

{[ 
{ 
"id":1, 
"userId":user1, 
"bookId":1, 
"rating":5.5, 
"note":"I liked the book but it was too long.", 
"url":http://server/reviews/1 
}, 
{ 
"id":2, 
"userId":user2, 
"bookId":1, 
"rating":1, 
"note":"boo, i didn't like it!", 
"url":http://server/reviews/2 
} 
]} 

Bewertungen von einem Benutzer /users/{user-id}/reviews

{[ 
{ 
"id":1, 
"userId":user1, 
"bookId":1, 
"rating":5.5, 
"note":"I liked the book but it was too long.", 
"url":http://server/reviews/1 
}, 
{ 
"id":2, 
"userId":user2, 
"bookId":1, 
"rating":1, 
"note":"boo, i didn't like it!", 
"url":http://server/reviews/2 
}, 
{ 
"id":5, 
"userId":user1, 
"bookId":3, 
"rating":2, 
"note":"I like to read", 
"url":http://server/reviews/5 
} 
]} 

Canonical Ressource für eine Bewertung /reviews/{review-id}

Erstellen einer neuen Überprüfung kann ein Beitrag für den Benutzer/Bewertungen, Buch/Bewertungen oder Bewertungen Ressourcen mit der Serverimplementierung von diesen POST-Service default Benutzer-ID oder Buch-ID wie angemessen.

Die Implementierung der URL-Link hat einige Optionen wie atom: link.

Ziehen Sie auch in Betracht, die rohe ID der Bücher, Benutzer und Rezensionen nicht dem Client/Verbraucher dieser Dienste auszusetzen und stattdessen die ID als URI verfügbar zu machen.