Mam kolekcję produktów w grupie produktów, np .:
product-groups/123/products
Jeśli muszę dodać do kolekcji, czy mogę przekazać tylko niektóre produkty z PUT?
Jeśli muszę usunąć niektóre produkty z kolekcji, czy mogę przesyłać dane filtru (tablicę identyfikatorów) za pomocą DELETE?
Jaki jest najlepszy sposób na wdrożenie funkcjonalności w duchu ReST?
Edycja: elementy to linki do oddzielnych jednostek, w zasadzie identyfikatory produktów.
rest
collections
użytkownik151851
źródło
źródło
Odpowiedzi:
Zasadniczo masz jeden punkt końcowy, który reprezentuje całą kolekcję x :
Powiedzmy, chcesz zaktualizować jeden produkt, dokonaniu PUT do
/products/{id}
. Jeśli chcesz częściowo zaktualizować pojedynczy produkt (nie aktualizując każdego pola), możesz również użyć PATCH do/products/{id}
. To samo dotyczy usunięcia pojedynczego elementu ( DELETE to/products/{id}
).Jeśli chcesz kierować pojedynczą ressource, kwalifikujesz torem, który pojedynczy Ressource, chcesz zmodyfikować.
Jedynym działaniem, które łamie schemat, jest utworzenie zasobu. Podczas tworzenia zasobu kierujesz kolekcję jako całość, powiedz POST na
/products
.To powiedziawszy, powinno być jasne, że cel operacji wpływających na kolekcję jako całość powinien trafić do odpowiedniego punktu końcowego gromadzenia.
Np. Chcesz odzyskać podzbiór produktów, które są czerwone, pytasz o to przez
GET do
/products?colour=red
.Tak więc, jeśli chcesz usunąć wszystkie z nich, to DELETE
/products?colour=red
. Lub jeśli chcesz usunąć niektóre z produktów za pośrednictwemid
, można DELETE/products?id=1&id=2&id=3
.Co z masowym tworzeniem zasobów? POST swoją kolekcję
[{...},{...},{...}]
po prostu/products
. To samo dotyczy PUT i PATCH .To naprawdę proste.
Aby odpowiedzieć na pytania:
To nie tylko OK, zachęcamy Cię do robienia tego w ten sposób.
W porządku. Jak napisał Eneko Alonso, czasami zdarzają się operacje zbiorcze za pomocą punktów końcowych „kontrolera”, tj. POST służy do wyzwalania (złożonych) operacji.
źródło
PATCH
i pełna wymiana za pośrednictwemPUT
.Zazwyczaj metody REST są przeznaczone do działania na pojedynczym obiekcie / obiekcie (CRUD).
Istnieje kilka opcji:
Pierwszy jest zgodny ze standardami REST, ale może być kosztowny, ponieważ obiekty / jednostki kolekcji mogą być bardzo duże (aktualizacja grupy, która ma tysiące produktów tylko w celu dodania / usunięcia jednego produktu, byłaby dużym żądaniem).
Druga opcja jest preferowana przez wiele interfejsów API, jako sposób na rozszerzenie REST poza operacje CRUD.
Na przykład:
Wiele interfejsów API zawsze używa POST dla tych rozszerzonych operacji, ale nic nie ogranicza korzystania z innych metod http (innych niż ograniczenie GET i DELETE, aby mieć puste ciało)
źródło
products/collection
zwraca „kopertę” elementów, a zawartość koperty zmienia się za pomocą PUT? Na przykład „oto dokładnie, jak chcę, aby elementy w kolekcji były”.Dokładnie poprzednie odpowiedzi / komentarze.
Zgodnie z moją wiedzą POST jest metodą dodawania pojedynczych elementów do kolekcji.
Z kolei DELETE to metoda usuwania pojedynczego elementu z kolekcji. Oba scenariusze są całkowicie PRZYWRACANE.
Należy jednak użyć odpowiedniego identyfikatora URI, aby odnieść się do pojedynczego elementu lub całej kolekcji.
Na przykład, aby dodać element do kolekcji, należy POST dane do następującego identyfikatora URI:
Aby usunąć pojedynczy produkt z kolekcji, możesz użyć metody DELETE wysyłającej żądanie do czegoś takiego:
Za pomocą metody PATCH można zaktualizować niektóre elementy w kolekcji. Na przykład, gdy musisz zaktualizować tylko jedno pole w jednym elemencie. Umieszczenie pełnej reprezentacji zasobów dla bardzo dużej kolekcji może być bardzo kosztownym działaniem.
źródło
Zasadniczo wszystkie operacje RESTful są poprawne dla kolekcji, ale upewnij się, że rozumiesz, jak semantyka czasowników ma zastosowanie do kolekcji:
PUT jest kompletnym zamiennikiem.
/item/{id}
) I pominieszname
, należy go wyczyścić lub ustawić na zero lub coś podobnego.Chociaż do dodania elementów można użyć PUT, musisz wysłać „wszystkie” elementy. Wysłanie „niektórych” elementów powinno spowodować usunięcie (zakładam, że nie tego chce OP).
DELETE jest bardziej intuicyjny. Poprawne jest usunięcie kolekcji lub dowolnego jej odfiltrowanego podzbioru. Wpływa to tylko na elementy zawarte w filtrze.
PATCH jest również ważny. Teoretycznie powinieneś podać listę „operacji”. Na przykład powinieneś technicznie wysłać coś takiego:
W praktyce częściej występuje interfejs API, który akceptuje częściową listę obiektów, w których każdy element jest przetwarzany za pomocą logiki UPSERT (aktualizacja lub wstawianie).
Technicznie, test POST powinien przetwarzać dane wejściowe „zgodnie z własną semantyką zasobu”.
{resource}/activate
.UWAGA: Podczas korzystania z operacji innych niż GET na kolekcjach, dokładnie rozważ definicję sukcesu i niepowodzenia. Usługa REST nie zapewnia dobrego sposobu komunikowania częściowego sukcesu. Dobrym rozwiązaniem domyślnym jest założenie, że operacja zostanie przeprowadzona w transakcji spełniającej kryteria sukcesu „wszystko albo nic”. Jeśli nie tego chcesz, prawdopodobnie nie powinieneś bezpośrednio wchodzić w interakcje z kolekcją.
źródło