RESTful atomic update of multiple resources?

Wyobraź sobie aplikację internetową przechowującą niektóre dane-zasoby z pewnym identyfikatorem, która przechowuje trzy załączniki (np.

Schemat URL to

data/{id}/attachment1
data/{id}/attachment2
data/{id}/attachment3

Istnieje RESTful API dla załączników dostarczających operacje GET/PUT/DELETE implementujące operacje CRUD po stronie serwera.

Pozwalając na id 123, chciałbym wykonać operację gdzie

• załączenie1 jest zastępowane przez nowy załącznik (taki, że GET file/123/attachment1 zwraca nowy załącznik)
• Załącznik 2 jest usunięty (tak, że GET file/123/attachment2 zwraca 404)
• załączenie3 pozostaje bez zmian.

Aktualizacja powinna być atomowa - kompletna aktualizacja jest wykonywana przez serwer lub nic w ogóle.

Stosowanie prostych PUT file/123/attachment1 i DELETE file/123/attachment2 nie jest atomowe, ponieważ klient może się zawiesić po PUT, a serwer nie ma wskazówki, że powinien zrobić rollback w tym przypadku.

Więc jak zaimplementować operację w RESTful sposób?

Myślałem o dwóch rozwiązaniach, ale oba nie wydają się być w 100% spokojne: {]}

• użyj patcha (można umieścić, ale PATCH lepiej odzwierciedla semantykę częściowej aktualizacji) z multipart/formularz-dane na dane / 123: The multipart/form-data jest sekwencją jednostek składających się z nowego "wniosek / pdf" związany z polem "załączenie1" oraz coś, co reprezentowałoby wartość null oznaczającą usunięcie dołączenie2.

Chociaż zapewnia to atomiczność, I wątpię, że jest to RESTful, ponieważ przeciążam metodę PATCH używając różnych list parametrów, co narusza ograniczenie uniform-interface.

• użyj zasobu reprezentującego transakcję. Mogę zamieścić dane id 123 do transakcji-URL, który utworzyłby zasób transakcji reprezentowanie kopii bieżącego stanu przechowywanego zasobu danych na serwerze, np. transaction / data / 123. Teraz mogę zadzwonić do PUT i Usunąć na załącznikach tego zasobu tymczasowego (np. DELETE transaction/data/123/attachment2) i komunikacja commit tej wersji zasobu do serwera poprzez PUT on transakcja / dane / 123. Zapewnia to atomiczność, podczas gdy trzeba zaimplementuj dodatkową logikę po stronie serwera, aby poradzić sobie z wieloma klientami zmiana tego samego zasobu i zawieszonych klientów, którzy nigdy się nie zobowiązali.

Trochę tu utknąłem, więc wszelkie pomysły byłyby pomocne, dzięki!