REStowy endpoint dodający wiersze do bazy danych - czy pozwalać na dodawanie zerowej ilości wierszy?

POST. W ciele POSTa lista obiektów, które należy umieścić w bazie danych. (Towary, których stan trzeba zaktualizować w blablabla.) Jeden towar, jeden wiersz do dodania do bazy.

Co, jeśli nadchodzi POST z pustą listą towarów?

Dla mnie to było oczywiste: 200 i no-op. Ale się admin czepnął, wymaga by w takiej sytuacji leciało 400. Zresztą inni ludzie tez mi mówili, że dodawanie pustej listy wierszy do bazy danych powinno być zabronione i kończyć się błędem. Nie rozumiem?

Tak chyba działa wszystko: na przykład:

List<Cośtam> l = blablabla;
l.AddRange(Enumerable.Empty<Cośtam>());

Dozwolona operacja, no-op.

Kolejny argument: Gdyby potraktować listę jako monadę, to dowolne operacje na pustej liście są dozwolone, ale są no-opem.

I jeszcze jeden argument, tym razem praktyczny: czasami takie podejście pozwala zaoszczędzić ifów.

Zdawało mi się - teraz myślę, że błędnie - że wynika to z tego, że niedawno skończyłem licencjat, a przecież informatyka to obecnie połowa matematyki. Wydawało mi się, że moja silna intuicja, że dodawanie pustej listy obiektów gdziekolwiek powinno być dozwolone wypływa właśnie z tej matematyki na studiach (na tej samej zasadzie, na której zero jest pełnoprawną ilością, a pusta lista jest pełnoprawną listą - rozumowałem, że dla ludzi bez choćby minimalnego wykształcenia matematycznego zero jest zaprzeczeniem ilości (bo ilość wskazuje na to, że coś jest, a zero mówi, że czegoś nie ma), zaś pusty zbiór to pojęcie wewnętrznie sprzeczne (z tego samego powodu)). Ale nawet ludzie po kilku matematycznych przedmiotach na studiach twierdzą, że dodawanie pustej listy do bazy winno byc zakazane, więc pewnie się myliłem.

I ostatni argument, nieco powiązany z powyższym: Ja bym rozumował, że operacja dodawania jakiejś listy obiektów do jakiegokolwiek zbioru (np. bazy danych) powinna kończyc się poprawnie, jeśli udało się doprowadzić do stanu, w którym spełniony jest warunek: dla każdego elementu listy jest on dodany. Jeśli lista jest pusta, to ten warunek jest spełniony na zasadzie vacuous truth, a więc operacja powinna zakończyć się sukcesem zawsze.

Czego nie rozumiem? Dlaczego RESTowy endpoint dodający wpisy do bazy winien zwrócić 400, jeśli lista wpisów jest pusta? Skąd sie biorą moje silne intuicje, że powinien to być zakończony sukcesem no-op?

Mi się wydaje, ze nie ma twardych branżowych zaleceń, a ludzie którzy mówią j/w to na zasadzie "punkt widzenia zależy od punktu siedzenia". Choć nie przywołam jakiś wielkich autorytetrów.
(1) Dla mnie subiektywnie no-op jest równie uprawnione

... z pewną myślą przeciw ...

(2) Ich wypowiedzi mogą zależeć od tego, co zwraca POST, np jest tradycyjna zasada zwracać ID / GUID / whatever nowo powstałych bytów, lub całe byty
I zwrócenie "nic" albo listy pustej może być źle rozumiana przez moduł klienta.
Czyli znów, spór nie ma obiektywnych rozstrzygnięć, a dogadanie

Myśl nr 3.
Hipotetycznie, gdyby lista nowelizacji otwierała jakiś obiekt do zapisu, dokonywała nowelizacji, zatwierdzała obiekt z wpisem w historii (logu, czymś podobnym), to pusta lista nowelizacji da fałszywy obraz "coś się działo" w postaci zmian statusu danej.

Znów, dogadanie

Gdy podchodzisz do kasy w sklepie z pustym koszykiem to nie słyszysz - dziękuje za zakupy, zapraszamy ponownie, a że jesteś naj***ny

Logika biznesowa to nie matematyka, a jeżeli matematyka robi jakiś problem, to tym gorzej dla niej, bo biznes jest ponadto :)

Serio, nie patrzyłbym tu z perspektywy REST czy matematyki, a po prostu czy biznesowo to ma sens.

Według mnie operacja aktualizacji 0 elementów jest dziwna i podejrzewałbym że brakuje jakiejś walidacji na GUI, gdzie ktoś może zaznaczać towary które mają zostać zaktualizowane i pomimo nie wybrania czegokolwiek, to przycisk był klikalny.

Jeżeli rzucisz błąd to może się zdarzyć tak, że na GUI użytkownik dostanie komunikat że nic nie wybrał i spróbuje jeszcze raz, a jak zwrócisz okejke, to może nic mu nie wyskoczyć i pomyśli że zrobił to co chciał.

Ale to takie gdybanie, ogólnie uważam że oba kody 200 i 400 mają sens.

@YetAnohterone: a jak przynosisz zakupy ze sklepu, to nie wykonujesz w ten sposób żadnej pracy, więc się nie męczysz?

@somekind:

Też nie rozumiem. pracy w sensie takim jak w matematyce <ins>fizyce</ins> czy normalnym? — KamilAdam 47 minut temu
W matematyce nie ma pracy. :P Ale Twój tok myślenia jest dobry. Skoro autor teoretyzuje w prawdziwym życiu, więc podałem mu przykład innego teoretyzowania, które jest w praktyce absurdalne. — somekind 12 minut temu

A, o to chodzi. Nie masz racji - z fizycznego punktu widzenia przenosząc zakupy ze sklepu do domu wykonuję pracę, gdyż muszę użyć siły by pokonać opory ruchu. Ponadto nawet wtedy, gdy trzymam zakupy w ręku ale nigdzie nie idę, i tak wykonuję pracę z fizycznego punktu widzenia, gdyż ludzkie mięśnie działają w ten sposób, że aby utrzymać coś w jednym miejscu pokonując siłę np. grawitacji, bez przerwy się kurczą i rozluźniają, toteż nigdy nie trzymam zakupów w rzeczywistości w jednym miejscu, tylko w bardzo krótkich odstępach czasu je odrobinę podnoszę i zaraz znowu opuszczam. Tym samym jest przesunięcie będące sumą tych małych przesunięć i w konsekwencji jest praca.

(Kiedy ciężar jest spory względem możliwości mięśni to zjawisko jest widoczne gołym okiem, ręka wyraźnie drży)

EDIT: Chociaż myślę, że sens Twojego posta jest trafny. Rzeczywiście chyba mam skłonności do nadmiernego teoretyzowania i obawiam się, że studia tylko pogorszyły tę przywarę u mnie. Zresztą ten post jest tego dowodem :)

W przypadku batchowych operacji nie spotkałem się z żadnym standardem. Tak naprawdę tutaj jest więcej kruczków, ponieważ pominąłeś istotny fakt - na backendzie walidacja może odrzucić cześć rekordów, w szczególności żaden może nie przejść. Musisz i tak ustalić kontrakt na częściowy zapis.

Abstrahując od tego, wysyłanie pustego payloadu niepotrzebnie dociąża sieć, to niegłupie żeby się umówić, ze takie requesty nie są obsługiwane - nie ma to sensu biznesowego.