2016-08-09 126 views
0

Ich bin etwas neu zu RESTful API Design-Praxis und auf der Suche nach Hilfe. Das Datenmodell, mit dem ich arbeite, beschreibt ein Objekt auf oberster Ebene (z. B. Book), das eine Liste verschachtelter Objekte (z. B. Kapitel) enthält.
Jedes Kapitel in seinem eigenen Recht beibehalten wird und ein simple_name Feld, das zu unique=True (dh. Nur einem Kapitel mit Chapter.simple_name = „ch_01“ existiert) gesetzt.REST API POST - Überprüfen Sie, ob jedes verschachtelte Objekt existiert. Wenn nein, erstellen Sie neu. Wenn ja, gebe das existierende Objekt zurück

Scenario: Ein Benutzer sendet eine Book ("myBook_v1"), die die Kapitel "ch_01", "ch_02" und "ch_03". Der Benutzer editiert dann sein Buch und die POSTs am nächsten Tag "myBook_v2" mit den Kapiteln "ch_01", "ch_02", "ch_03", und "ch_04". Angenommen, die Kapitel "ch_01", "ch_02", "ch_03" sind gegenüber dem ursprünglichen POST unverändert.

Derzeit seit simple_name erforderlich ist einzigartig zu sein, die zweiten POST nicht passieren Einzigartigkeit Validierung und eine Fehlerantwort an den Benutzer zurückgegeben.

Frage: Würde die folgende Implementierung REST Designprinzipien passen? Und, am wichtigsten, ist das eine gute (sichere) Designwahl?

Implementierung: Auf Büchersendung, überprüfen Sie jeden Chapter.simple_name für Einzigartigkeit. Wenn Chapter.Simplename bereits in der Datenbank vorhanden ist, überspringen Sie die Erstellung. Wenn es nicht existiert, erstellen Sie ein neues Kapitel. Rückgabe des vollständig persistenten Buches mit einer Mischung aus neu erstellten Kapiteln und bereits vorhandenen Kapiteln. Das einzige Kriterium für die Entscheidung, neu zu erstellen oder zu verwenden, besteht darin, ob die benutzerspezifische einfache_name für ein Kapitel in der Datenbank bereits vorhanden ist.

Antwort