Co zwrócić po utworzeniu zasobu?

2

Powiedzmy, że mam widok z listą produktów (eh, znowu te produkty) i dialog (modal) pozwalający na dodanie produktu. Jak najlepiej zaktualizować listę produktów po dodaniu produktu (zamknięciu dialogu)?

  1. Pobrać od nowa listę produktów z API
  2. Zwrócić z endpointu POST /api/products dane nowo utworzonego produktu i na ich podstawie zaktualizować stan aplikacji
  3. Nic nie zwracać z endpointu, zaktualizować stan na podstawie danych z formularza, wygenerować timestampy w JSie, a ID pobrać z headera Location

Kiedy wybrać którą opcję? Czy któraś z opcji to rak, na którego należy uważać?

6

Chyba prawidłowo będzie zwrócić 201, w tym nowo utworzony obiekt i/lub URL do tego obiektu w nagłówku Location.

0

Możesz też zobaczyć Post, Redirect, Get

0

Czytalem kiedys o PRG, ale czy to nie dotyczy tylko klasycznych aplikacji zwracajacych HTMLa?

Zwrocenie JSONa byloby proste, ale czy to nie lamie CQRS? Bo zwrocenie calego obiektu to jednak nie to samo co zwrocenie samego ID - trzeba wykonac mapowanie itd.

1

Ja bym po dodaniu produktu (tj. zamknięciu dialogu) odświeżył listę produktów.
W przypadku gdy lista jest paginowana i posortowana (a tak zwykle jest) nie wiadomo
czy dany produkt wgl powinien się pojawić na liście a po odświeżeniu listy produkt
ładnie się wpasuje tam gdzie jego miejsce.

0

Ok, to byl slaby przyklad. Dlatego zalozmy, ze nie mamy paginacji, bo produktow jest bardzo malo :)

1

Wybieram bramkę numer 4) pierw POST zwraca Ci id/Location nowo utworzonego produktu, a potem robisz GET i pobierasz ten produkt i dodajesz do listy, a framework js robi swoją magię i uaktualnia ui :)

opcja 2 jest niezgodna z REST nic więcej poza ID/Location POST nie może zwrócić, a opcja 3 to stąpanie po kruchym lodzie bo może się okazać zupełnie coś innego zostało dodane do bazy, także alternatywnie pozostaje 1) jak się nie przejmujemy wydajności i jesteśmy leniwi

i tak, PRG nie ma zastosowania przy wysyłaniu formularzy jsem

0

Id ze zwrotki do onClicka + 3

Po co marnować bandwidth?

2

Generalnie, to zależy. I bez konkretnych przykładów ciężko wybrać najlepszą opcję. A czasem może pasować kilka.

  1. Spoko, jeśli coś się może nie udać po drodze. Do tego trochę się komplikuje, bo samo odświeżenie od razu może nie pomóc. Pisałeś o CQRS, wtedy bardziej czekasz na event z serwera (może być SignalR albo Firebase albo coś innego) że produkt został dodany. I dopiero wtedy możesz "odświeżyć" listę. Tutaj bardzo dużo zależy od konkretnego wykorzystania i możliwych scenariuszy.
    Np kiedy działa to tak:
    Wysyłasz request z produktem. Serwer go akceptuje w sensie potwierdza otrzymanie. -> Wiesz że request ("prośba") o dodanie jest dostarczona, ale nie wiesz czy zaakceptowana. (logika biznesowa, dodatkowa walidacja, poszukiwanie duplikatów, ręczna akceptacja przez człowieka, jakiś proces w tle, itp, itd).
    Serwer po jakimś czasie (hej, może być i 0.2 sekundy, zwykle tak będzie) akceptuje i wysyła Ci powiadomienie. (albo i nie, wtedy musisz ręcznie odświeżać, trochę słabo ale da się).
    Tutaj odróżniłbym poranie całej listy produktów a zaktualizowanie listy przechowywanej w pamięci o dodanie nowego elementu. I tu znów zależy jak często taka lista ma się zmieniać, czy jak inny użytkownik coś zmieni to ma się każdemu aktualizować itd itp. Generalnie pobieranie całej listy będzie słabe jeśli jest duża. Jeśli to operacja jaką wykonujesz raz na tydzień i lista jest np 5 elementowa - who cares? Jeśli robi się to kilka razy na minutę i ma się odświeżać wszystkim, co trzeba to inaczej zorganizować. Można połączyć z opcją numer dwa zamiast powiadomień z serwera wysyłanych innym kanałem.
    2.Spoko jak się da i wydajność na tym nie cierpi. Np jeśli to zwykła crudowa operacja. Fajniejsze od 3, jeśli zwracasz jakieś dodatkowe dane na temat produktu. Łączy się z tym co napisałem wcześniej, jeśli dodanie produktu jest dość szybkie.
  2. Spoko, jeśli wiesz że operacja zawsze się uda, albo nie jest to ważne że się nie udała (ktoś napisze komentarz na FB, nie dodało się, ale użytkownik myśli że już każdy może go wyświetlić - trudno, kupuję produkty, moja płatność nie przeszła, użytkownik musi o tym wiedzieć natychmiast... żeby zapłacił :P).
0
  1. To rozwiązanie wybrałbym tylko w przypadku kiedy kolejność produktów na liście ma ściśle określone znaczenie biznesowe i zwyczajnie nie wiesz który w kolejności będzie dodany przedmiot. W przeciwnym razie wydaje mi się, że pobieranie wszystkich elementów po dodaniu jednego jest po prostu złym rozwiązaniem.

  2. Według mnie najlepsze rozwiązanie, otrzymujesz aktualne dane lub odnośnik to nich

  3. Czasami serwer może zmienić wysłane przez Ciebie dane lub dodać do nich dodatkowe informacje, więc traktowanie 'niepewnych' danych z formularza nie wydaje mi się dobrym rozwiązaniem

1 użytkowników online, w tym zalogowanych: 0, gości: 1