RESTful Alternatywy dla żądania usunięcia ciała

Question

Podczas gdy HTTP 1.1 spec wydaje się zezwalać na żądania ciał na żądania , wydaje się, że serwery powinny go zignorować, ponieważ nie ma dla niego zdefiniowanej semantyki.

4,3 Treść wiadomości

Serwer powinien przeczytać i przekazać wiadomość-ciało na każde żądanie; jeśli metoda żądania nie zawiera zdefiniowanej semantyki dla jednostki-podmiotu, , wówczas treść komunikatu POWINIEN być zignorowana podczas obsługi żądania.

Już przeglądowi kilka podobnych dyskusji na ten temat na SO i poza nią, takie jak:

• Is an entity body allowed for an HTTP DELETE request?
• Payloads of HTTP Request Methods
• HTTP GET with request body

Większość dyskusji wydają się zgadzają się, że podanie treści wiadomości na DELETE może być dozwolone , ale generalnie nie jest zalecane.

Co więcej, zauważyłem trend w różnych bibliotekach klientów HTTP, w których coraz więcej ulepszeń wydaje się być rejestrowanych dla tych bibliotek, aby obsługiwać ciałach żądań przy usuwaniu. Większość bibliotek wydaje się zobowiązywać, choć czasami z niewielkim początkowym oporem.

Mój przypadek użycia wymaga dodania niektórych wymaganych metadanych podczas operacji DELETE (np. "Przyczyna" usunięcia, a także kilka innych metadanych wymaganych do usunięcia). Mam rozważyć następujące opcje, z których żadna nie wydają się całkowicie właściwe i inline ze specyfikacją HTTP i/lub reszta najlepszych praktyk:

• Treść wiadomości - Spec wskazuje, że treść wiadomości na DELETE nie mają wartości semantycznej; nie w pełni obsługiwany przez klientów HTTP; niestandardowa praktyka
• Niestandardowe nagłówki HTTP - Wymaganie niestandardowych nagłówków jest zwykle następujące: against standard practices; ich używanie jest niezgodne z resztą mojego API, z których żaden nie wymaga niestandardowych nagłówków; Ponadto, nie jest dobre odpowiedzi HTTP dostępny do wskazania wartości nagłówków złe niestandardowych (prawdopodobnie osobną pytanie łącznie)
• standardowe nagłówki HTTP - Brak standardowe nagłówki są odpowiednie
• Parametry zapytania - tworzenie kwerendy params faktycznie zmienia się request- Identyfikator URI został usunięty; against standard practices
• Metoda POST - (np. POST /resourceToDelete { deletemetadata }) POST nie jest opcją semantyczną do usuwania; POST faktycznie reprezentuje odwrotny działania pożądanego (tj POST tworzy podwładnych zasobów, ale muszę usunąć zasób)
• wiele metod - podział żądanie DELETE na dwie operacje (np PUT usuwać metadane, a następnie usunąć) dzieli operacja atomowa na dwie, potencjalnie pozostawiając niespójny stan.Przyczyna usunięcia (i inne powiązane metadane) nie są częścią samej reprezentacji zasobów.

Moją pierwszą preferencją byłoby prawdopodobnie użycie treści wiadomości, a po drugie niestandardowe nagłówki HTTP; jednak, jak wskazano, istnieją pewne wady tych podejść.

Czy istnieją jakieś zalecenia lub najlepsze praktyki zgodne ze standardami REST/HTTP dotyczące uwzględniania takich wymaganych metadanych w żądaniach DELETE? Czy są jakieś inne alternatywy, których nie rozważałem?

Answer 1

Pomimo pewnych zaleceń, aby nie używać treści wiadomości w przypadku żądań DELETE, takie podejście może być odpowiednie w niektórych przypadkach użycia. Takie podejście wykorzystaliśmy po ocenie innych opcji wymienionych w pytaniu/odpowiedziach i po współpracy z konsumentami usługi.

Podczas gdy użycie treści wiadomości nie jest idealne, żadna z pozostałych opcji nie była idealnie dopasowana. Jednostka DELETE żądania pozwoliła nam łatwo i wyraźnie dodać semantykę wokół dodatkowych danych/metadanych, które były niezbędne do operacji DELETE.

Byłbym nadal otwarty na inne myśli i dyskusje, ale chciałem zamknąć pętlę na to pytanie. Doceniam wszystkie myśli i dyskusje na ten temat!

Answer 2

Biorąc pod uwagę sytuację trzeba, chciałbym mieć jedną z następujących metod:

• Wysyłanie PUT lub plastra: Jestem wydedukował, że operacja usuwania jest wirtualny, ze względu na charakter konieczności DELETE powód. Dlatego uważam, że aktualizowanie rekordu za pomocą operacji PUT/PATCH jest prawidłowym podejściem, mimo że nie jest to operacja DELETE jako taka.
• Użyj parametrów zapytania: Zasób uri nie jest zmieniany. Uważam, że jest to również prawidłowe podejście. Pytanie, które łączysz, dotyczyło braku zezwolenia na usunięcie, jeśli brakowało parametru zapytania. W twoim przypadku miałbym tylko domyślny powód, jeśli powód nie jest określony w ciągu zapytania. Zasób będzie nadal resource/:id. Możesz to uczynić wykrywalnym dzięki nagłówkom Link w zasobach dla każdego powodu (z etykietą rel na każdym z nich, aby zidentyfikować przyczynę).
• Użyj osobnego punktu końcowego według przyczyny: Za pomocą adresu URL, takiego jak resource/:id/canceled. To faktycznie zmienia Request-URI i zdecydowanie nie jest REST. Ponownie, nagłówki linków mogą sprawić, że będzie to wykrywalne.

Pamiętaj, że REST nie jest prawem ani dogmatem. Pomyśl o tym bardziej jako o przewodniku. Tak więc, kiedy nie ma sensu nie stosować się do wskazówek dotyczących twojej domeny problemowej, nie rób tego. Tylko upewnij się, że Twoi klienci korzystający z API są poinformowani o wariancji.

Answer 3

Proponuję dołączyć wymagane metadane jako część samej hierarchii URI. Przykład (Naiwny):

Jeśli chcesz usunąć wpisy na podstawie zakresu dat, zamiast podawania daty początkowej i końcowej w treści lub parametrów zapytania, utwórz URI w taki sposób, aby przekazywać wymagane informacje jako część URI.

np.

DELETE /entries/range/01012012/31122012 - Usuń wszystkie wpisy od 01 stycznia 2012 do 31 grudnia 2012

nadzieję, że to pomaga.

Answer 4

Co wydaje się chcieć to jedna z dwóch rzeczy, z których żadna nie jest czystym DELETE:

1. Masz dwie operacje, z PUT o powód usunięcia następnie DELETE zasobu. Po usunięciu zawartość zasobu nie jest już dostępna dla nikogo. "Przyczyna" nie może zawierać hiperłącza do usuniętego zasobu. Lub
2. Próbujesz zmienić zasób z state=active na state=deleted, używając metody DELETE.Zasoby ze stanem = usunięte są ignorowane przez główny interfejs API, ale mogą być nadal odczytywane przez administratora lub osobę z dostępem do bazy danych. Jest to dozwolone - DELETE nie musi usuwać danych z kopii zapasowej zasobu, tylko w celu usunięcia zasobu ujawnionego przy tym identyfikatorze URI.

Każda operacja, która wymaga treść wiadomości na żądanie DELETE można podzielić na co to jest najbardziej Generalnie, POST zrobić wszystkie niezbędne zadania z treści wiadomości oraz DELETE. Nie widzę powodu, aby łamać semantykę HTTP.