Co zwrócić po utworzeniu zasobu?

Odpowiedz Nowy wątek
2019-10-09 17:57
1

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ć?

edytowany 2x, ostatnio: nobody01, 2019-10-09 18:01
"Kiedy wybrać którą opcję? Czy któraś z opcji to rak, na którego należy uważać?" Bardzo dobrze zadane pytanie. - AreQrm 2019-10-10 11:29

Pozostało 580 znaków

2019-10-09 19:02
6

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


Na każdy złożony problem istnieje rozwiązanie które jest proste, szybkie i błędne.

Pozostało 580 znaków

2019-10-09 19:25
0

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


Spring? Ja tam wole mieć kontrole nad kodem ᕙ(ꔢ)ᕗ
Haste - mała biblioteka do testów z czasem.

Pozostało 580 znaków

2019-10-09 20:00
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.

Pozostało 580 znaków

2019-10-09 20:18
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.

Pozostało 580 znaków

2019-10-09 20:29
0

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

Pozostało 580 znaków

2019-10-09 20:56
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


It's easy to hate code you didn't write, without an understanding of the context in which it was written.
edytowany 5x, ostatnio: neves, 2019-10-09 21:07

Pozostało 580 znaków

2019-10-09 21:08
0

Id ze zwrotki do onClicka + 3

Po co marnować bandwidth?

edytowany 1x, ostatnio: WeiXiao, 2019-10-09 21:08

Pozostało 580 znaków

2019-10-10 11:46
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).

żeby być zgodnym z restem to w sumoe request http powinien tworzyć request stworzenia czegos na serwerze i zwracać urla tego request i klient moze sobie sprawdzać co jakiś czas ten request czy ju skonczył się przetwarzać i wtedy dopiero pobrać wynik - danek 2019-10-10 11:48

Pozostało 580 znaków

Odpowiedz
Liczba odpowiedzi na stronę

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