Czy serwer powinien „być pobłażliwy” pod względem akceptacji i „odrzucać po cichu błędne dane wejściowe”?

Miałem wrażenie, że do tej pory wszyscy zgadzają się, że ta maksyma była błędem. Ale ostatnio widziałem tę odpowiedź, która ma „łagodny” komentarz, który był oceniany 137 razy (na dzień dzisiejszy).

Moim zdaniem pobłażliwość w akceptowaniu przeglądarek była bezpośrednią przyczyną totalnego bałaganu, jaki HTML i niektóre inne standardy sieciowe miały kilka lat temu, a dopiero niedawno zaczęły właściwie krystalizować się z tego bałaganu. Sposób, w jaki ja to widzę, łagodny w tym, co akceptujesz , doprowadzi do tego.

Druga część maksymy to „odrzuć wadliwe dane w trybie cichym, bez zwracania komunikatu o błędzie, chyba że jest to wymagane przez specyfikację” , a to wydaje się być obraźliwe. Każdy programista, który uderzył głową w ścianę, gdy coś się nie powiedzie, będzie wiedział, co mam na myśli.

Czy więc całkowicie się mylę? Czy mój program powinien być łagodny w tym, co akceptuje i cicho połykać błędy? Czy też źle interpretuję, co to znaczy?

Pierwotne pytanie brzmiało „program”, a ja o tym wszystkim myślę. Programy mogą być łagodne. Jednak tak naprawdę miałem na myśli interfejsy API: interfejsy udostępnione innym programom , a nie ludziom. HTTP jest przykładem. Protokół jest interfejsem używanym tylko przez inne programy. Ludzie nigdy nie podają bezpośrednio dat, które wpisują się w nagłówki, takie jak „Jeśli-zmodyfikowano-od”.

Pytanie zatem brzmi: czy serwer implementujący standard powinien być łagodny i dopuszczać daty w kilku innych formatach oprócz tego, który jest rzeczywiście wymagany przez standard? Uważam, że „łagodność” powinna odnosić się do tej sytuacji, a nie do ludzkich interfejsów.

Jeśli serwer jest łagodny, może się to wydawać ogólną poprawą, ale myślę, że w praktyce prowadzi to tylko do implementacji klienta, które ostatecznie polegają na łagodności i tym samym nie działają z innym serwerem, który jest łagodny w nieco inny sposób.

Czy serwer ujawniający niektóre interfejsy API powinien być łagodny, czy to bardzo zły pomysł?

Teraz na łagodną obsługę danych wprowadzanych przez użytkownika. Rozważ YouTrack (oprogramowanie do śledzenia błędów). Używa języka do wprowadzania tekstu, który przypomina Markdown. Tyle że jest „łagodny”. Na przykład pisanie

- foo
- bar
- baz

to nie udokumentowany sposób tworzenia listy punktowanej, a mimo to działało. W rezultacie zostało to często używane w naszym wewnętrznym narzędziu do wykrywania błędów. Pojawia się kolejna wersja, a ta łagodna funkcja zaczyna działać nieco inaczej, łamiąc garść list, które (źle) używały tej (nie) funkcji. Oczywiście udokumentowany sposób tworzenia list wypunktowanych nadal działa.

Czy moje oprogramowanie powinno być łagodne w zakresie akceptowanych danych wejściowych ?

Oczywiście masz całkowitą rację. Programy nigdy nie powinny być „łagodne”, ponieważ służą jedynie do maskowania problemów. Problemy należy podkreślać, a nie zamiatać pod dywan. Informacyjny komunikat o błędzie jest absolutną koniecznością, aby program był pomocny dla użytkownika.

Przez większość czasu, gdy podawane są niepoprawne / nieprawidłowe dane, dostawca tych danych (niezależnie od tego, czy jest to użytkownik, czy dane wyjściowe innego programu) prawdopodobnie nie wiedział, że są one nieprawidłowe. Połknięcie błędu sprawi, że będą przekonani, że jest (lub może być) ważny, co powoduje rozpowszechnianie nieprawidłowych danych.

Jedynym sposobem na współdziałanie systemów jest pełne i jednoznaczne zdefiniowanie tej współpracy. Program, który akceptuje dane spoza specyfikacji, de facto akceptuje te dane, nawet jeśli są one nieprawidłowe przez specyfikację, co nie tylko utrudnia zgodność, ale także oznacza, że ​​nie jest już formalnie zdefiniowane. Sam program jest teraz de facto standardem. Dlatego łagodnych programów nie można dalej rozwijać ani zastępować, ponieważ nie można wprowadzić najmniejszych zmian w sposobie ich działania.

Myślę, że wszystko zależy od tego, kim jest twoja docelowa grupa demograficzna. Jeśli to programiści, to absolutnie nie. Twój program powinien zawieść mocno i wykrzyczeć krwawe morderstwo. Jednakże, jeśli twoi odbiorcy docelowi nie są programistami, twój program powinien być łagodny, gdzie może z gracją obsługiwać wyjątki, w przeciwnym razie szepcz słodkie krwawe morderstwo.

Jako studium przypadku weź odtwarzacz NPAPI Flash. Istnieje wersja „release” dla tych, którzy tak naprawdę nie dbają o 99% błędów, które mogą wystąpić, ale jest też wersja „debugująca”, która krzyczy krwawe morderstwo, gdy coś pójdzie nie tak. Każde wsparcie odtwarza treści Flash oczywiście, ale są kierowane na dwie zupełnie różne dane demograficzne.

Ostatecznie myślę, że ważne jest to: na czym troszczą się Twoi użytkownicy?

Istnieją dwa rodzaje „łagodnych”: Jednym z nich jest zaakceptowanie niepoprawnych danych wejściowych i próba ich zrozumienia, a drugim akceptacja różnych typów danych wejściowych.

Ogólnie rzecz biorąc, zawsze chcesz mieć drugi, gdy jest to wykonalne. Po pierwsze, umierasz szybko i ciężko. Przykład: daty.

Oto kilka przykładowych danych wejściowych, w tym poprawne, nieprawidłowe i niejednoznaczne.

• 2011-01-02
• 01/02/2011
• Jan 2, 2011
• 2-Jan-2011
• Green

Jest tylko jeden nieważny wejścia tutaj: Green. Nawet nie próbuj zaakceptować tego jako daty. Ponieważ Greenoczywiście nie jest to data, jest to przypadek, w którym ciche wyciszenie jest dopuszczalne.

01/02/2011jest poprawny, ale niejednoznaczny. Niekoniecznie wiesz, czy została wprowadzona jako data amerykańska (2 stycznia), czy nie (1 lutego). Tutaj prawdopodobnie najlepiej jest zawieść głośno i poprosić użytkownika o jednoznaczną datę.

2011-01-02jest zwykle uważany za jednoznaczny, więc często dobrze jest założyć, że ma format „RRRR-MM-DD”, i kończy się niepowodzeniem. Jest to jednak trochę osąd w przypadku wprowadzania danych przez użytkownika.

Jan 2, 2011i 2-Jan-2011są ważne i jednoznaczne, należy je zaakceptować. Jednakże, The Second of January of the year 2011jest również ważne i jednoznaczne, ale dzieje się tak daleko w trosce o leniency jest przesadą. Idź naprzód i po cichu zawiedź Green.

Krótko mówiąc , odpowiedź brzmi „to zależy”. Sprawdź, co można wprowadzić, i upewnij się, że nigdy nie akceptujesz sprzecznych typów danych wejściowych (takich jak DD/MM/YYYYvs MM/DD/YYYY).

W kontekście powiązanego pytania / komentarza jest to przypadek 2011-01-02. Dane wejściowe wyglądają jak JSON i sprawdzają poprawność jak JSON, nawet jeśli typ mimetyczny jest nieprawidłowy; śmiało i spróbuj użyć go, nawet jeśli zawiedzie w pewnym momencie niżej.

Cicha porażka jest najgorszą rzeczą, jaką możesz zrobić. Czy próbowałeś debugować interfejs API z cichą awarią? To niemożliwe .

Jest tam napis „Zrób wszystko, aby odzyskać, ale wyślij szczegółowy błąd” i „Cicha awaria”.

Wydaje mi się, że Prawo Postela - „Bądź konserwatywny w tym, co robisz, bądź liberalny w tym, co akceptujesz od innych” - jest przedmiotem dyskusji na temat usługi JSON. Zwykle dotyczy to usług internetowych, a nie interfejsu użytkownika.

W przypadku konstruktywnej informacji zwrotnej od użytkownika i ograniczania wkładu użytkownika stosujemy zasadę.

Myślę, że jest to dobrze omówione w rozdziale 1, sekcji 6 TAOUP. W szczególności reguła naprawy , która mówi, że program powinien robić to, co może z wejściem, przekazywać poprawne dane do przodu, a jeśli poprawna odpowiedź nie powiedzie się, zrób to jak najszybciej.

Podobną koncepcją jest programowanie obronne . Ty nie wiesz, jakiego rodzaju wejścia otrzymasz, ale program powinien być wystarczająco wytrzymałe, aby objąć wszystkie przypadki. Oznacza to, że należy zaprogramować w przypadkach odzyskiwania znanych problemów, takich jak zniekształcone dane wejściowe, i przechwytywać wszystkie przypadki, aby obsłużyć nieznane.

Więc dyskretne odrzucanie wadliwych danych wejściowych jest w porządku, o ile sobie z nimi radzisz. Nigdy nie powinieneś po prostu upuszczać go na podłogę.

W przypadku API myślę, że pobłażliwość jest taka sama jak w przypadku programu. Dane wejściowe są nadal niepoprawne , ale próbujesz naprawić jak najwięcej. Różnica polega na tym, co uważa się za prawidłową naprawę . Jak zauważyłeś, łagodny interfejs API może powodować problemy, ponieważ ludzie używają „funkcji”, które nie istnieją.

Oczywiście API jest tylko wersją niższej wersji reguły składu . Jako taki, jest naprawdę objęty zasadą najmniejszego zaskoczenia , ponieważ jest interfejsem.

Jak zauważa cytat ze Spencera, unikaj powierzchownego podobieństwa, które można argumentować na temat „rozmytych” danych wejściowych. W tych warunkach zwykle twierdzę, że wszystko wskazuje na niemożność naprawy programu, ponieważ nie będzie wiedział, co jest pożądane, i jest to najmniej zaskakujące dla bazy użytkowników.

Masz jednak do czynienia z datami, które mają wiele „standardów”. Czasami nawet mieszają się w jednym programie (łańcuch). Ponieważ wiesz, że data jest oczekiwana, próba rozpoznania daty jest po prostu dobrym projektem. Zwłaszcza jeśli data pochodzi z jakiegoś programu zewnętrznego i jest przekazywana niezmodyfikowana przez sekundę w drodze do ciebie.

Programy wdrażane na serwerze przez większość czasu powinny przyjmować tysiące żądań co minutę, a czasem co sekundę. Jeśli program serwera zaakceptuje i poprawi błędne dane wejściowe od klientów, obawiam się, że będą miały 2 wady:

1. Utrata cennego czasu serwera. Przy ponad 1000 żądań na sekundę sprawdzanie błędów w każdym żądaniu może odzwierciedlać powolną odpowiedź dla każdego klienta.
2. Nieuczciwe wobec klienta / programów klienckich, które zapewniają prawidłowe dane wejściowe. Poza tym, gdy programista po stronie serwera siedzi na kodzie serwera, musi pomyśleć o różnych przypadkach, jakie mogą być nieprawidłowe dane wejściowe. Kto to zadecyduje?

Programy serwera nie powinny przyjmować błędnych danych wejściowych, ale serwery powinny zwracać klientowi komunikat o błędzie, jeśli dane wejściowe są błędne.

Idealnie, pod względem koncepcyjnym, jest robienie tego, co można zrobić bezpiecznie, przy jednoczesnym zapewnieniu, że ktoś, kto może naprawić jakiekolwiek problemy, zostanie w jakiś sposób powiadomiony o nich. W praktyce, oczywiście, ostatnie ograniczenie jest często niemożliwe do spełnienia bezpośrednio, dlatego pytanie staje się najlepsze w przypadku podejrzanych danych wejściowych.

Jedną z rzeczy, która może być bardzo pomocna w projektowaniu protokołu, specyfikacji formatowania lub „języka”, jest możliwość rozróżnienia czterech kategorii potencjalnych niezrozumiałych elementów:

1. Rzeczy, które należy odfiltrować, jeśli nie są zrozumiane.
2. Rzeczy, które powinny zostać zignorowane, jeśli nie zrozumiane, ale mimo to zachowane, jeśli dane muszą zostać przekazane (być może w jakimś opakowaniu, aby wskazać, że przeszedł przez co najmniej jeden etap, który go nie zrozumiał)
3. Rzeczy, które powinny wygenerować ostrzeżenie, jeśli nie są zrozumiane, ale nie powinny uniemożliwiać próby odzyskania danych (np. Na stronie internetowej, obiekt, którego typ jest nieznany, ale którego koniec w pliku jest dobrze zdefiniowany, może być renderowany jako czerwony „X” bez uniemożliwienia renderowania reszty strony).
4. Rzeczy, które wskazywałyby na to, że wszystko, co ich nie rozumie, może mieć poważne i niemożliwe do naprawienia problemy w innym miejscu (np. Wskaźnik, że pozostałe dane są kompresowane i które są zrozumiałe dla wszystkiego, co mogłoby wykonać wymaganą dekompresję).

Posiadanie dobrze zdefiniowanej konwencji, według której aplikacje potrafiące odczytać dowolną wersję formatu danych będą mogły rozpoznać, która kategoria jest odpowiednia dla wszystkiego, co jest generowane zgodnie z późniejszymi wersjami, jest znacznie lepszym podejściem niż próba zastosowania środków zgodności ad-hoc później. Na przykład, jeśli format pliku ma wiersze w postaci „Tag: Value”, można określić, że pierwszy znak dowolnego tagu wskaże kategorię, do której należy; w przypadku znaczników kategorii cichego ignorowania pierwszy znak może również wskazywać wersję standardu, dla którego znacznik ma być poprawny (tak, że jeśli znacznik „ciche ignorowanie” twierdzi, że jest obecny w wersji 3 standard, parser dla wersji po cichu go zignoruje, ale parser dla wersji 3 lub nowszej skurczyłby się, gdyby nie mógł go przeanalizować).

Najważniejsze w każdym przypadku jest uniknięcie przekształcania niejednoznacznych lub źle zrozumianych danych w błędne dane. W niektórych przypadkach lepszym rozwiązaniem może być w ogóle odmowa propagowania niejednoznacznych danych, ale w innych przypadkach lepsza może być propagacja dokładnie w takiej postaci, w jakiej je otrzymano, na wypadek gdyby odbiorca uznałby je za jednoznaczne. To, co naprawdę niebezpieczne, jeśli wręcz nie zło, to konwersja danych przy użyciu różnych założeń, np. Konwersja listy dat, takich jak:

01.12.12
13.12.12
99/12/12

na listę dat takich jak

2012-01-12
13.12.2012
1999-12-12

Nawet jeśli ktoś miał listę z kilkoma błędnie wprowadzonymi datami, człowiek może mieć listę w oryginalnym formacie, aby ustalić, który format jest poprawny, i oznaczyć wątpliwe wartości do dalszych badań (porównanie z innymi rekordami itp. ) Renderowanie dat w tym ostatnim formacie byłoby jednak beznadziejne i nieodwracalne.

Moje wrażenia z interfejsu użytkownika pochodzą głównie z systemów stacjonarnych. Strony internetowe są różne, chociaż widziałem kilka witryn, które mogą stanowić wyzwanie dla systemu komputerowego. Ale za co warto:

Odkryłem, że komunikaty o błędach powinny być ostatecznością; idealny system w ogóle ich nie miałby. Najlepiej jest przede wszystkim nie dopuścić do złych wpisów: użytkownik nie może wpisać „zielony”, jeśli wybiera z rozwijanej listy miesięcy. Nie może nacisnąć szarego przycisku.

Następną najlepszą rzeczą jest zaakceptowanie złych danych. Załóżmy, że wyświetlasz histogram dziennej sprzedaży za miesiąc. Po wprowadzeniu przez użytkownika wykres obejmuje wiek, a słupek na wiek jest 10 razy wyższy niż pozostałe. Użytkownik wie teraz, że zrobił coś złego, a ponadto wie dużo więcej o tym, co zrobił źle, niż jakakolwiek wiadomość mogłaby mu powiedzieć. Gdy wpis jest graficzny - na przykład poprzez przeciągnięcie myszą - tego rodzaju opinie nadal działają i są nieocenione. Kilka danych wejściowych może być niepoprawnych, ale przy użyciu tej metody użytkownik otrzymuje natychmiastową, szczegółową informację zwrotną na temat wyników każdej pozycji myszy.

To powiedziawszy, czasami użytkownik musi wiedzieć, dlaczego przycisk jest wyszarzony, aby nie mógł go nacisnąć. Wtedy nie ma na to rady (jeśli nie jest , daj mi znać), ale do ungray przycisk, a kiedy kliknie na nim, dać mu dobre wyjaśnienie dlaczego przycisk nie działa w tej chwili.

Oświadczenie dotyczy wysyłania informacji przez Internet. Jedną z rzeczy związanych z wysyłaniem informacji przez Internet jest to, że nie zawsze dociera ona do celu w ogóle lub jest fragmentaryczna.

Coś, co wydaje się tutaj pominięte - jakie są konsekwencje niepowodzenia?

Wyświetlić stronę internetową? Powinieneś zrobić wszystko, aby tolerować złe dane wejściowe. Masz do wyboru, co możesz wyświetlić lub zgłosić błąd. Ten ostatni kurs nie daje użytkownikowi nic, a zatem powinien być jedynie ostatecznością, ponieważ daje użytkownikowi całkowicie bezużyteczny wynik, byłoby ciężko, aby błąd był gorszy niż ten.

Z drugiej strony, jeśli prosi o cel Minutemana III, odrzucasz „Moskwę” jako dane wejściowe, ponieważ jest to potencjalnie niejednoznaczne.