Czy można częściowo zmienić kolekcję za pomocą PUT lub DELETE?

Mam kolekcję produktów w grupie produktów, np .:

product-groups/123/products

1. Jeśli muszę dodać do kolekcji, czy mogę przekazać tylko niektóre produkty z PUT?

2. 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.

Zasadniczo masz jeden punkt końcowy, który reprezentuje całą kolekcję x :

/products

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średnictwem id, 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:

Jeśli muszę dodać do kolekcji, czy mogę przekazać tylko niektóre produkty z PUT?

To nie tylko OK, zachęcamy Cię do robienia tego w ten sposób.

Jeśli muszę usunąć niektóre produkty z kolekcji, czy mogę przesyłać dane filtru (tablicę identyfikatorów) za pomocą DELETE?

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.

Zazwyczaj metody REST są przeznaczone do działania na pojedynczym obiekcie / obiekcie (CRUD).

Istnieje kilka opcji:

• Traktuj swoje kolekcje jako byty i aktualizuj je za pomocą POST
• Twórz alternatywne operacje bez REST

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:

GET product-groups/123/products (list all the products in the group)
POST product-groups/123/products/append (POST a list of new product ids to append to the group)
POST product-groups/123/products/remove (POST a list of product ids to remove from the group)

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)

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:

https://www.factory.net/products/

Aby usunąć pojedynczy produkt z kolekcji, możesz użyć metody DELETE wysyłającej żądanie do czegoś takiego:

https://www.factory.net/products/108/

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.

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.

  • Jeśli umieścisz w singletonie (np. /item/{id}) I pominiesz name, należy go wyczyścić lub ustawić na zero lub coś podobnego.
  • Jeśli umieszczasz w kolekcji i nie zawierasz elementu, należy go usunąć z tej kolekcji.

  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:

  [{ 
      "action": "update",
      "id": <id>,
      "value": {...}
  },{
      "action": "add",
      "value": {...}
  }, ...]
  

  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”.

  • W praktyce POST jest zwykle używany do operacji „tworzenia”.
  • Jednak POST jest także czasownikiem używanym do niestandardowych połączeń. Chociaż toczy się energiczna debata na temat tego, czy punkty końcowe działania są RESTfully (ja jestem po stronie „nie”), POST jest odpowiednim czasownikiem, jeśli składasz żądanie do punktu końcowego, takiego jak {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ą.