Jeśli usunąłeś zasobu używając DELETE kolejnych żądań do zasobu powinny powrócić 404 NOT FOUND lub 410 GONE ponieważ nie ma już zasób nie akceptować żądań.
Jeśli jest to akceptowalne, a stan jest dostępny, najprostszą odpowiedzią jest po prostu ponowne utworzenie zasobu przez wydanie PUT na adres URL usuniętego zasobu. Semantycznie tworzy to nowy zasób, zastępując dowolny istniejący stan, nie naprawiając faktycznie usunięcia.
Innym prostym rozwiązaniem jest przyznanie, że faktycznie nie usuwasz zasobów i zmieniasz ich stan tylko w taki sposób, aby pokazać, że są archiwizowane. Oznacza to, że nie można używać czasownika DELETE, ale można wysyłać żądania do zasobu w celu zmiany między stanem zarchiwizowanym a stanem aktywnym.
Jeśli chcesz zachować DELETE jako swój sposób usuwania rekordów, wówczas rozwiązaniem jest umożliwienie uzyskania dostępu do archiwum zasobów poprzez zastosowanie specjalnej show-archived wartość:
GET /contacts/<id>?show-archived=true
Podanie tej na zasadzie zarchiwizowane zasoby zwrócą numer 200 na zarchiwizowany zasób zamiast jednego z kodów 40X. Trochę to niefortunne, ponieważ twoje zasoby mają teraz problem "superpaństwa" pojawiania się, istniejącego i nieistniejącego, w zależności od tego, jak je obserwujesz. To jednak nie oznacza, że można złożyć wniosek do zasobu aktualizować swój stan:
PUT /contacts/<id>?show-archived=true
State=Active
... all other unchanged fields ...
+1 - kolejna niewielka odmiana to PATCH, ponieważ logicznie tylko aktualizujesz część zasobu (w tym przypadku jest to stan usunięty/zarchiwizowany) – bryanmac
'PATCH' być bardzo odpowiedni do tego typu wniosków, jednak poparcie dla niego jest różne; jest to całkiem nowa w rodzinie czasowników HTTP. –