REST - Tworzenie zasobów zagnieżdżonych z pojedynczym POST

Question

Myślenie w sposób RESTOWNOWY, czy prawidłowe jest używanie testu POST do utworzenia w jednym wywołaniu zasobu i jego pod-zasobu? W mojej aplikacji mam zasób /notices/{notice} i sub-zasób /notices/{notice}/photos/{photo}. A {photo} nie może istnieć bez {notice}, ale {notice} nie musi koniecznie mieć zdjęć. Normalnie muszę najpierw zrobić POST, aby utworzyć powiadomienie, następnie kolejny POST, aby dodać zdjęcie.

Teraz chcę zezwolić na utworzenie ogłoszenia ze zdjęciem bezpośrednio dołączonym, umożliwiając utworzenie /notices/{notice} i /notices/{notice}/photos/{photo} z pojedynczym żądaniem POST do/notice/{notice}/photos/{photo}, z treścią wieloczęściową opisujące oba zasoby (JSON dla ogłoszenia, plik binarny dla zdjęcia). Myślę, że zwrócę nagłówek Location tylko dla pod-zasobu.

Zasadniczo chcę, aby uniemożliwić klientom Android wysłanie dwóch żądań POST do serwera w celu przesłania powiadomienia ze zdjęciem. Czy to prawda? Czy może narusza zasady REST? Czy powinienem rozważyć ich oddzielenie i złożenie dwóch różnych wniosków? Czy też niewłaściwe jest uznawanie zdjęć za osobny przedmiot z ogłoszenia? Czy powinienem przechowywać tylko /notices/{notice} jako źródło, używając PUT do dodawania zdjęć?

Jakie jest najlepsze rozwiązanie?

Answer 1

Tak, nie ma nic złego w tworzeniu pod-zasobów w tym samym czasie, gdy tworzony jest zasób nadrzędny. Byłoby nawet w porządku, aby użyć PUT zamiast POST, aby to zrobić, ponieważ wszystko pod macierzystym adresem URL jest częścią/należy do zasobu, który przesyłasz.

EDIT:

Teraz chcę, aby umożliwić tworzenie zawiadomienia ze zdjęciem bezpośrednio przyłączone, umożliwiając tworzenie /notices/{notice} i /notices/{notice}/photos/{photo} z jednym POST żądanie /notices/{notice}/photos/{photo}

Tego się nie zgadzam. Proponuję POSTing do adresu URL źródła kolekcji, /notices. Podajesz powiadomienie i jego zdjęcia jako pojedyncze przedstawienie (treść wniosku). Back-end stworzy zasoby zarówno dla ogłoszenia, jak i dla dowolnych składowych zdjęć.

Answer 2

Chociaż jest to niezbędne w wielu przypadkach, wiele edycji/tworzenia nie jest formalnie adresowanych w stylu architektury RESTful.

Problem rozpoczyna się, gdy trzeba zgłosić awarie w części kolekcji, a problem ulega pogorszeniu, gdy awarie mają inną przyczynę.

Wpłynie to na wybór odpowiednich kontrolek Hypermedia, które są niezbędne klientowi do znalezienia drogi naprzód w danej transakcji/rozmowie.

Moja sugestia to raczej zagnieżdżony cykl lub żądania POST niż singlowy POST, aby utworzyć zagnieżdżone zasoby, aby łatwiej było wyjaśnić każdą zmianę stanu zasobu.