RESTful sposób tworzenia wielu elementów w jednym żądaniu

Pracuję nad małym programem serwera klienta do zbierania zamówień. Chcę to zrobić w „REST (pełny) sposób”.

Chcę tylko:

Zbierz wszystkie zamówienia (produkt i ilość) i wyślij całe zamówienie na serwer

W tej chwili widzę dwie opcje, aby to zrobić:

1. Wyślij każdy wiersz zamówienia na serwer: POST qty i product_id

Właściwie nie chcę tego robić, ponieważ chcę ograniczyć liczbę żądań do serwera, więc opcja 2:

2. Zbierz wszystkie zamówienia i wyślij je na serwer jednocześnie.

Jak wdrożyć opcję 2? Mam kilka pomysłów: Zawiń wszystkie linie zamówienia w obiekt JSON i wyślij to na serwer lub użyj tablicy, aby opublikować linie zamówienia.

Czy dobrym pomysłem lub dobrą praktyką jest wdrożenie opcji 2, a jeśli tak, to jak mam to zrobić.

Co to jest dobra praktyka?

Uważam, że innym właściwym sposobem rozwiązania tego problemu byłoby stworzenie innego zasobu, który reprezentuje twoją kolekcję zasobów. Przykład, wyobraź sobie, że mamy punkt końcowy taki jak /api/sheep/{id}i możemy POST w /api/sheepcelu utworzenia zasobu owiec.

Teraz, jeśli chcemy wspierać tworzenie zbiorcze, powinniśmy rozważyć nowy zasób stada pod adresem /api/flock(lub /api/<your-resource>-collectionjeśli brakuje ci lepiej zrozumiałej nazwy). Pamiętaj, że zasoby nie muszą być mapowane do Twojej bazy danych lub modeli aplikacji . To powszechne nieporozumienie.

Zasoby to reprezentacja wyższego poziomu, niezwiązana z Twoimi danymi. Operowanie na zasobie może mieć znaczące skutki uboczne, takie jak wysłanie ostrzeżenia do użytkownika, aktualizacja innych powiązanych danych, zainicjowanie długotrwałego procesu itp. Na przykład moglibyśmy zmapować system plików lub nawet pspolecenie unixa jako REST API.

Myślę, że można bezpiecznie założyć, że działanie zasobu może oznaczać również tworzenie kilku innych podmiotów jako efekt uboczny.

Chociaż operacje zbiorcze (np. Tworzenie wsadowe) są niezbędne w wielu systemach, nie są formalnie uwzględniane w stylu architektury RESTful.

Zauważyłem, że udostępnianie kolekcji zgodnie z sugestią w zasadzie działa, ale pojawiają się problemy, gdy trzeba zgłosić awarie w odpowiedzi na takie żądanie. Takie problemy są gorsze, gdy występuje wiele awarii z różnych przyczyn lub gdy serwer nie obsługuje transakcji. Moja sugestia jest taka, że ​​jeśli nie ma problemu z wydajnością, na przykład gdy usługodawca jest w sieci LAN (nie WAN) lub dane są stosunkowo małe, warto wysłać 100 żądań POST do serwera. Zachowaj prostotę, zacznij od oddzielnych żądań, a jeśli masz problem z wydajnością, spróbuj zoptymalizować.

Facebook wyjaśnia, jak to zrobić: https://developers.facebook.com/docs/graph-api/making-multiple-requests

Proste żądania grupowe

Batch API przyjmuje tablicę logicznych żądań HTTP reprezentowanych jako tablice JSON - każde żądanie ma metodę (odpowiadającą metodzie HTTP GET / PUT / POST / DELETE itp.), Względny_url (część adresu URL po graph.facebook. com), opcjonalna tablica nagłówków (odpowiadająca nagłówkom HTTP) i opcjonalna treść (dla żądań POST i PUT). Interfejs Batch API zwraca tablicę logicznych odpowiedzi HTTP reprezentowanych jako tablice JSON - każda odpowiedź ma kod stanu, opcjonalną tablicę nagłówków i opcjonalną treść (która jest ciągiem zakodowanym w formacie JSON).

Twój pomysł wydaje mi się ważny. Realizacja zależy od Twoich preferencji. Możesz użyć do tego JSON lub po prostu parametrów (tablica „order_lines []”) i zrobić

POST /orders

Ponieważ zamierzasz stworzyć więcej zasobów naraz w jednej akcji (zamówienie i jego wiersze), ważne jest, aby zweryfikować każdy z nich i zapisać je tylko wtedy, gdy wszystkie przejdą walidację, tj. powinieneś to zrobić w transakcji.

Myślę, że lepiej jest wysyłać oddzielne żądania w ramach jednego połączenia . Oczywiście twój serwer WWW powinien to obsługiwać

Ostatnio się z tym zmagałem i oto nad czym pracuję.

Jeśli POST, który dodaje wiele zasobów, powiedzie się, zwróć 200 OK (rozważałem 201, ale użytkownik ostatecznie nie trafia do utworzonego zasobu) wraz ze stroną, która wyświetla wszystkie dodane zasoby, albo jako przeczytane -tylko lub edytowalna moda. Na przykład użytkownik może wybrać i POST wiele obrazów do galerii przy użyciu formularza zawierającego tylko jeden plik wejściowy. Jeśli żądanie POST zakończy się powodzeniem w całości, użytkownikowi przedstawiany jest zestaw formularzy dla każdej utworzonej reprezentacji zasobu obrazu, który pozwala mu określić więcej szczegółów na temat każdego z nich (nazwa, opis itp.).

W przypadku niepowodzenia tworzenia co najmniej jednego zasobu, program obsługi POST przerywa przetwarzanie i dołącza każdy komunikat o błędzie do tablicy. Następnie zwracany jest 419 Conflict, a użytkownik jest kierowany do strony błędu 419 Conflict, która przedstawia zawartość tablicy błędów, a także drogę powrotną do przesłanego formularza.

Nie będziesz chciał wysyłać nagłówków HTTP dla 100 linii zamówienia. Nie chcesz generować więcej żądań niż to konieczne.

Wyślij całe zamówienie w jednym obiekcie JSON na serwer na adres: serwer / zamówienie lub serwer / zamówienie / nowy. Zwróć coś, co wskazuje na: server / order / order_id

Rozważ także użycie CREATE PUT zamiast POST