REST Teilweise Aktualisierung auf mehrere Ressourcen

Ich habe zwei Arten von Ressourcen, Geschäfte und Artikel, ein Geschäft kann eindeutig identifiziert werden, indem es ID, ein Geschäft enthält eine Reihe von verschiedenen Arten von Artikeln.Gegenstände haben im Allgemeinen ihren Typ zu identifizieren beispielsweise hat ein Leiterkabel von Modell A einen Code von 265, ein Codeelement 265 kann in mehr als einem Geschäft existieren. Beispiel HTTP-Anfragen und ihre Antworten.REST Teilweise Aktualisierung auf mehrere Ressourcen

GET /stores/1/items 
    [{ 
    "itemCode": 265, 
    "itemDescription": "Conductor cable", 
    "itemModel": "model1", 
    "uom":"meter", 
    "quantity": 30 
    }, 
    { 
    "itemCode": 122, 
    "itemDescription": "Low-fat Milk", 
    "itemModel": "model2", 
    "uom":"liter", 
    "quantity": 15 
    }] 
GET /stores/2/items 
    [{ 
    "itemCode": 265, 
    "itemDescription": "Conductor cable", 
    "itemModel": "model1", 
    "uom":"meter", 
    "quantity": 25 
    }] 


GET /stores/3/items 
    [{ 
    "itemCode": 122, 
    "itemDescription": "Low-fat Milk", 
    "itemModel": "model2", 
    "uom":"liter", 
    "quantity": 20 
    }]

was ich möchte ein REST-API-Endpunkt haben, die den Api Verbraucher bewegen lassen würde, sagen 10 Meter Leiterkabel von model1 von Speicher 1 2. zu speichern Ich weiß, es ist die Möglichkeit, mit zwei PATCH HTTP-Anfragen, um dies zu erreichen, indem die Mengen in den Läden 1 und 2 aktualisiert werden, aber ich muss dies mit einer einzigen HTTP-Anfrage erreichen.

Quelle

2017-08-23 ahmedjaad

'PATCH' [kann Nebenwirkungen haben] (https://tools.ietf.org/html/rfc5789#section-2) und ändern Sie mehrere Ressourcen auf einmal, daher können Sie mehrere Ressourcen mit einer einzigen Anfrage ändern –

PATCH ist nicht wirklich erholsam. Ich sehe keinen Weg, wie REST alleine das lösen kann, da es sich im Allgemeinen nur um einzelne Ressourcen handelt.

Die einzige wahre RESTful Weise, die ich sehe, ist Ressourcen für jedes Modell zu erstellen (Sie sollten dies wahrscheinlich sowieso tun) und von diesem Modell ändern, welche Sammlung es gehört (collection Relationstyp).

Ich sehe keine Links in Ihren Beispielen, also nehme ich an, dass Sie nicht wirklich nach einem echten REST-Ansatz suchen. In diesem Fall würde ich sagen, dass eine benutzerdefinierte POST Anfrage wahrscheinlich hier gut genug ist.

Quelle

2017-08-23 14:07:23 Evert

Warum Sollte 'PATCH' nicht RESTful sein? Welche Einschränkungen verletzt es, um nicht RESTful zu sein? Es war sogar [vorgeschlagen von Roy Fielding] (https://twitter.com/fielding/status/275471320685367296), der eigentlich auch REST vorschlug. –

Ich denke, dass Thread Tweets alles ist, was Sie wissen müssen. Liest du etwas, das ich nicht lese? PATCH sendet effektiv eine Reihe von Anweisungen zum Ändern einer Ressource. Es überträgt den Status nicht. – Evert

In diesem Zusammenhang ist 'POST' auch nicht RESTful, da die Semantik vom Implementierer definiert wird und Sie grundsätzlich senden können, was Sie wollen, und dies kann den Status einer oder mehrerer Ressourcen beeinflussen oder auch nicht. Während es bei REST nur um Ressourcen geht, ist es in Ordnung, wenn Sie Anweisungen an den Dienst senden, die ihm mitteilen, wie eine Ressource geändert werden muss, um einen bestimmten Status zu erreichen. Sie können auch einen Zustandsübergang erreichen, indem Sie mit 'PUT' updaten, allerdings mit weniger Effizienz, da Sie die gesamte aktualisierte Sammlung senden müssen. Worin besteht der Unterschied zu der Last der zu sendenden Daten in beiden Fällen? –

Wenn Sie dies mit HTTP PATCH erreichen wollen, dann sollte JSON Patch - RFC 6902 hilfreich sein. Es ermöglicht das Senden mehrerer Operationen innerhalb einer einzelnen Anforderung, sodass mehrere Ressourcen und Eigenschaften gleichzeitig aktualisiert werden können. Wenn eine Operation fehlschlägt, sollte der gesamte Patch ebenfalls fehlschlagen. Innerhalb einer Anfrage müssen Sie jedoch die neue Endmenge eines Artikels angeben. Sie können keine Operation zum Abziehen vom aktuellen Wert definieren. Damit diese Lösung in einer Mehrbenutzerumgebung funktioniert, ist ein optimistischer Sperrmechanismus ein Muss. Sonst ist eine Datenkorruption unvermeidlich.

HTTP POST ist eine gute Alternative. Das Verschieben einer gewissen Menge eines Artikels von einem Geschäft in ein anderes ist vergleichbar mit der Überweisung von Geld zwischen Bankkonten. In diesem Fall würde ich den folgenden Endpunkt erstellen: POST /stores/item-transfer. Der Anfragetext würde den Quellspeicher/itemCode/itemQuantity und den Zielspeicher enthalten. Alle Zustandsänderungen würden innerhalb einer einzigen Transaktion stattfinden.

Persönlich bin ich für den POST-Ansatz, aber wenn Sie PATCH bleiben und Java ist Ihre Sprache, dann würde ich vorschlagen, die Tomoko Bibliothek zu RFC 6902 Anfragen zu verarbeiten. Ich bin sein Autor.

Quelle

2017-09-05 07:36:07

REST Teilweise Aktualisierung auf mehrere Ressourcen

Antwort

Verwandte Themen