nieprzewidywalny format danych

Nieprzewidywalny format danych to odpowiedzi zmieniające strukturę między wywołaniami, wymuszające obronne parsowanie.

Na czym polega nieprzewidywalny format danych

Nieprzewidywalny format danych występuje wtedy, gdy system zwraca informacje o zmiennej strukturze, mimo że kolejne wywołania dotyczą pozornie tego samego zasobu lub operacji. Zmiana może dotyczyć typu danych, nazwy pola, poziomu zagnieżdżenia, liczby elementów tablicy albo sposobu sygnalizowania błędu. Przykładowo jedno wywołanie interfejsu programistycznego może zwrócić obiekt JSON zawierający pole items jako tablicę, a inne — obiekt z polem item reprezentującym pojedynczy element. Dla człowieka oba wyniki mogą oznaczać to samo, lecz dla programu są różnymi strukturami.

Problem nie ogranicza się do odpowiedzi JSON. Może pojawić się w plikach CSV o zmiennej liczbie kolumn, danych XML z opcjonalnymi elementami, komunikatach przesyłanych przez sieć, wynikach poleceń systemowych oraz danych odczytywanych z plików konfiguracyjnych. Nieprzewidywalność może być zamierzona, na przykład gdy odpowiedź zależy od liczby wyników, albo wynikać z błędu po stronie programu generującego dane. Szczególnie ryzykowna jest sytuacja, w której dokumentacja opisuje jeden format, ale rzeczywiste odpowiedzi zawierają dodatkowe warianty nieuwzględnione w opisie.

Typowe źródła zmienności odpowiedzi

Jednym ze źródeł problemu jest różne kodowanie sukcesu i błędu. Przy poprawnym wykonaniu żądania program może otrzymać obiekt zawierający pola data i status, natomiast przy błędzie — tablicę komunikatów albo obiekt z polem error. Jeżeli aplikacja zawsze próbuje odczytać data["items"], odpowiedź błędna może spowodować wyjątek KeyError, błąd typu albo przerwanie całego procesu. Podobny efekt wystąpi, gdy pole ma zwykle wartość liczbową, lecz w sytuacji braku wartości pojawia się null lub pusty tekst.

Zmienność bywa także następstwem niejednoznacznej reprezentacji pojedynczego i wielu wyników. Niektóre programy zwracają obiekt dla jednego rekordu oraz tablicę dla wielu rekordów. Inne zmieniają nazwę pola zależnie od wersji komponentu, parametrów zapytania albo uprawnień użytkownika. Błąd może powstać również przez łączenie danych z kilku źródeł, które używają innych nazw, jednostek lub formatów daty. Data zapisana jako 2026-08-26 nie jest równoważna tekstowi 26.08.2026 bez dodatkowej reguły interpretacji. Jeszcze większe ryzyko pojawia się przy liczbach zapisanych raz jako liczby, a raz jako teksty, na przykład 12 i "12".

Obronne parsowanie i walidacja struktury

Obronne parsowanie polega na tym, że program nie zakłada bezwarunkowo obecności każdego pola i nie ufa samemu faktowi, że dane dają się odczytać składniowo. Najpierw należy sprawdzić, czy odpowiedź ma oczekiwany typ, na przykład czy główny wynik jest obiektem, tablicą lub tekstem. Następnie warto zweryfikować obecność wymaganych pól, ich typy oraz zależności między nimi. Dla danych JSON można użyć schematu opisującego dozwolone właściwości, typy wartości i pola obowiązkowe. Walidacja powinna rozróżniać brak pola, wartość null, pustą tablicę i pusty tekst, ponieważ każda z tych sytuacji może mieć inne znaczenie.

Bezpieczny parser powinien normalizować dopuszczalne warianty do jednego modelu wewnętrznego. Jeżeli źródło zwraca pojedynczy rekord albo tablicę rekordów, warstwa wejściowa może zawsze przekazywać dalej listę, również jednoelementową. Jeżeli pole jest opcjonalne, aplikacja powinna jawnie określić wartość domyślną albo oznaczyć brak informacji, zamiast przypadkowo traktować brak jako zero lub pusty tekst. W przypadku nieznanej struktury parser powinien zapisać informację diagnostyczną, odrzucić wadliwy rekord lub przekazać kontrolowany błąd. Nie należy automatycznie ignorować wszystkich dodatkowych pól, ponieważ mogą wskazywać na zmianę kontraktu danych.

Rozpoznawanie problemu w działającej aplikacji

Diagnozę warto rozpocząć od porównania kilku rzeczywistych odpowiedzi dla tego samego działania. Należy sprawdzić kod odpowiedzi HTTP, nagłówek Content-Type, pełną strukturę danych oraz moment wystąpienia błędu. Sam komunikat o nieprawidłowym polu nie wyjaśnia jeszcze, czy przyczyną była zmiana po stronie usługi, nieobsłużony wariant błędu, uszkodzony plik czy błędna konwersja danych. Pomocne jest zapisanie zanonimizowanego przykładu odpowiedzi poprawnej i problematycznej oraz wskazanie różnicy między nimi: brakującego klucza, zmienionego typu, innego poziomu zagnieżdżenia lub dodatkowego separatora.

Podczas sprawdzania laptopa lub komputera PC analizuje się logi aplikacji, wersję używanego programu, ustawienia połączenia oraz pliki, z których dane są pobierane. Należy ustalić, czy błąd pojawia się za każdym razem, tylko dla określonych danych, po aktualizacji programu, czy przy chwilowej niedostępności źródła. Jeżeli problem występuje po zmianie wersji aplikacji, trzeba porównać kontrakt danych i sposób jego interpretacji. Warszawskie Pogotowie Komputerowe zajmuje się profesjonalną naprawą laptopów, komputerów PC i ich podzespołów, dlatego w ramach diagnostyki można przeanalizować działanie programu oraz ustalić, czy przyczyną jest konfiguracja, uszkodzenie plików, niezgodność wersji lub błąd w obsłudze danych.