Ich habe eine Entität mit mehreren Attributen, sagen Sie «Projekt». Abgesehen von einfachen Attributen kann das Projekt eine Liste von "Status" haben, von denen der letzte der aktuelle ist. Ich habe ein Webformular zum Erstellen / Bearbeiten eines Projekts. Alle Attribute dieses Projekts können in dieser Form geändert werden, und Benutzer können auch einen neuen Status für das Projekt hinzufügen (sie können jedoch keine alten Status ändern oder löschen).
Projektstatus sind rein zusammengesetzte Entitäten, sie haben keine unterscheidbare Bedeutung oder Identität außerhalb des Projektumfangs, und sie sind nicht direkt adressierbar, daher verdienen sie offensichtlich keine spezielle root REST-Ressource. p>
Gemäß der REST-Architektur habe ich eine Ressource namens / projects erstellt. POST wird verwendet, um ein neues Projekt zu erstellen, und PUT wird verwendet, um ein vorhandenes Projekt zu ändern.
Ich möchte jedoch nicht, dass der Client das Projekt zusammen mit all seinen historischen Status PUT, weil erstens diese Sammlung zu schwer ist, und zweitens weil die Geschäftslogik nur das Hinzufügen von Status zulässt, sie nicht ändert oder löscht Das Projekt zusammen mit all seinen Status zu posten, macht sowieso keinen Sinn.
Das Hinzufügen eines Projekts mit nur einem neuen Status ist ebenfalls keine Option, da es die Idempotenz von PUT verletzt.
Ich mag auch nicht die Idee, einen Status in einer zweiten HTTP-Anfrage, sagen wir / project / {id} / status, zu POSTIEREN, weil das die Atomizität der Aktualisierungsoperation vom Standpunkt des Benutzers aus brechen würde. Wenn diese zweite Anforderung auf dem Draht verloren geht, wird das Projekt für den Benutzer, der es bearbeitet hat, inkonsistent angezeigt (die Attribute wurden geändert, der Status blieb jedoch gleich). RESTful "Transaktionen" zu erstellen, erscheint als Overkill (und auch fehleranfällig) für diese einfache Aufgabe der Aktualisierung einer scheinbar monolithischen Entität.
Diese Art von Problem ist in meiner Arbeit ziemlich allgegenwärtig und kann als solche verallgemeinert werden: Was ist der RICHTIGE, korrekte und atomare Weg zum Aktualisieren einer komplexen zusammengesetzten Entität, für die die Geschäftslogik nur eine teilweise Aktualisierung erlaubt?
> Ich denke, wenn du partielle Updates machen willst (es ist tatsächlich dein Fall), solltest du die Methode PATCH verwenden. Dadurch kann entweder das Projekt ohne Abhängigkeiten (Status) oder die Abhängigkeit (en) ohne die Projekthinweise aktualisiert werden.
Sie können feststellen, dass es ein Format gibt, um die Vorgänge innerhalb einer Methode PATCH zu beschreiben. Es heißt JSON Patch (siehe Ссылка ). Dieses Format beschreibt, was Sie in Ihrer Anfrage tun möchten: fügen Sie ein Element hinzu, aktualisieren Sie es, entfernen Sie es, ...
Ich denke, dass Sie so etwas haben könnten, wenn Sie (zum Beispiel) den Namen eines bestimmten Projekts aktualisieren, einen Status entfernen möchten (es ist auch ein Beispiel, seit ich gelesen habe, dass Sie dies verbieten wollen!) und ein hinzufügen neue in einer atomaren Anfrage:
%Vor% Beachten Sie, dass Sie das Attribut name verwenden können, um das zugehörige Element im Ressourcenstatus zu identifizieren. So kann /statuses/1 das zweite Element im Array sein, der Status mit der ID des Wertes 1 oder etwas anderes.
Die serverseitige Verarbeitung für die Anforderung kann atomar sein.
Ich habe einen Blogpost über Bulk-Updates geschrieben: Ссылка . Ich denke, dass der Abschnitt "Implementieren von Bulk-Updates" dem entsprechen könnte, wonach Sie suchen.
Hoffe es hilft dir, Thierry
Tags und Links rest design restful-architecture