REST steht dem exakt gleichen Problem wie SOAP-basierte Web-Services in Bezug auf atomare Transaktionen gegenüber. Es gibt keine stateful Verbindung, und jede Operation wird sofort begangen; Durch das Ausführen einer Reihe von Operationen können andere Clients Zwischenzustände sehen.
Es sei denn natürlich, Sie kümmern sich von diesem Design. Fragen Sie sich zuerst: habe ich eine Standard-Reihe von atomaren Operationen? Dies ist üblicherweise der Fall. Zum Beispiel ist für eine Bankoperation das Entfernen einer Summe von einem Konto und das Hinzufügen der gleichen Summe zu einem anderen Konto oft eine erforderliche atomare Operation. Anstatt jedoch nur die primitiven Bausteine zu exportieren, sollte die REST-API eine einzelne "Transfer" -Operation bereitstellen, die den gesamten Prozess einkapselt. Dies stellt die gewünschte Atomizität bereit und vereinfacht gleichzeitig den Client-Code. Diese Appracoh ist bekannt als niedrige Granularität Dienstleistungen oder High-Level-Batch-Operationen.
Wenn es keine einfache, vordefinierte Gruppe von gewünschten atomaren Operationssequenzen gibt, ist das Problem schwerwiegender. Eine übliche Lösung ist das Batch-Befehlsmuster. Definieren Sie eine REST-Methode, um den Beginn einer Transaktion abzugrenzen, und eine weitere, um ihr Ende abzugrenzen (eine Commit-Anforderung). Alles, was zwischen diesen Vorgangsgruppen gesendet wird, wird vom Server in die Warteschlange gestellt, aber nicht festgeschrieben, bis die Übermittlungsanforderung gesendet wird.
Dieses Muster kompliziert den Server erheblich - es muss einen Status pro Client beibehalten. Normalerweise gibt die erste Operation ('begin transaction') eine Transaktions-ID (TID) zurück, und alle nachfolgenden Operationen bis einschließlich Commit müssen diese TID als Parameter enthalten.
Es ist eine gute Idee, eine Zeitüberschreitung für Transaktionen zu erzwingen: Wenn zu viel Zeit seit der ersten Transaktion 'Beginne Transaktion' oder seit dem letzten Schritt vergangen ist, hat der Server das Recht, die Transaktion abzubrechen. Dies verhindert einen möglichen DoS-Angriff, der dazu führt, dass der Server Ressourcen verschwendet, indem er zu viele Transaktionen offen lässt. Das Client-Design muss berücksichtigen, dass jede Operation auf eine Zeitüberschreitung überprüft werden muss.
Es ist auch eine gute Idee, dem Kunden zu erlauben, eine Transaktion abzubrechen, indem er eine "Rollback" API bereitstellt.
Die übliche Sorgfalt beim Entwerfen von Code, der mehrere gleichzeitige Transaktionen verwendet, gilt wie üblich in diesem komplexen Entwurfsszenario. Versuchen Sie, wenn möglich, die Verwendung von Transaktionen einzuschränken, und unterstützen Sie stattdessen Batch-Operationen auf hoher Ebene.
Ich übernehme keine Kredit dieser Informationen, ich bin nur ein Regisseur, geht Kredit This article
Lesen Sie auch bitte Transactions in REST?
Sie können einige nützliche Codebeispiele hier http://www.it-soa.eu/en/resp/atomicrest/userguide/index.html