brak odpowiedzi 200 OK

Brak odpowiedzi 200 OK to usterka API sygnalizująca, że żądanie nie zostało pomyślnie przetworzone przez serwer.

Co oznacza brak statusu 200 OK

Brak odpowiedzi 200 OK oznacza, że klient API nie otrzymał od serwera odpowiedzi z kodem HTTP 200 (OK), który standardowo potwierdza pomyślne przetworzenie żądania. Nie jest to jednak nazwa jednej, konkretnej awarii. Serwer mógł zwrócić inny kod HTTP, na przykład 400, 401, 403, 404, 405, 408, 429 albo kod z zakresu 500, lub połączenie mogło zostać przerwane zanim klient otrzymał jakikolwiek nagłówek odpowiedzi.

W praktyce trzeba odróżnić „brak kodu 200” od „braku odpowiedzi HTTP”. Kod 404 oznacza, że zasób lub ścieżka nie zostały znalezione, 401 wskazuje na brak prawidłowego uwierzytelnienia, a 403 na odmowę dostępu mimo rozpoznania żądania. Kod 405 informuje o niedozwolonej metodzie HTTP, na przykład użyciu GET w punkcie końcowym wymagającym POST. Odpowiedzi 500, 502, 503 i 504 zwykle wskazują na problem po stronie serwera, pośrednika albo usługi zależnej.

Rozróżnienie błędu protokołu od przerwanego połączenia

Jeżeli klient otrzymuje kod HTTP różny od 200, odpowiedź nadal istnieje na poziomie protokołu HTTP i może zawierać nagłówki, treść diagnostyczną oraz identyfikator błędu. Inaczej wygląda sytuacja, gdy pojawia się przekroczenie czasu oczekiwania, błąd rozwiązywania nazwy DNS, odmowa połączenia, błąd TLS albo reset połączenia TCP. W tych przypadkach program może nie otrzymać statusu HTTP wcale, ponieważ komunikacja zatrzymała się przed ukończeniem wymiany nagłówków.

Znaczenie ma również sposób obsługi odpowiedzi przez aplikację. Kod klienta może traktować każdą odpowiedź inną niż 200 jako wyjątek, choć niektóre interfejsy używają także innych poprawnych statusów, takich jak 201 Created po utworzeniu zasobu, 202 Accepted po przyjęciu zadania do wykonania lub 204 No Content po pomyślnym żądaniu bez treści odpowiedzi. Dlatego diagnoza powinna uwzględniać dokumentację danego endpointu, metodę HTTP, oczekiwany kod oraz format danych, a nie tylko prosty warunek „status == 200”.

Ślad diagnostyczny w żądaniu API

Podstawowe sprawdzenie powinno obejmować dokładny adres URL, metodę HTTP, parametry zapytania, nagłówki oraz treść żądania. Literówka w ścieżce, nieprawidłowy port, brak prefiksu wersji API albo wysłanie danych jako nieobsługiwany typ MIME może prowadzić do odpowiedzi 404, 400 lub 415. W przypadku żądań wymagających uwierzytelnienia trzeba zweryfikować obecność nagłówka Authorization, poprawność tokenu i jego aktualność. Należy także sprawdzić zegar systemowy, ponieważ znaczne odchylenie czasu może powodować odrzucanie podpisanych lub czasowo ograniczonych żądań.

W logach warto zapisać moment rozpoczęcia żądania, metodę, ścieżkę bez poufnych danych, kod odpowiedzi, czas trwania, rozmiar odpowiedzi oraz identyfikator korelacyjny. Przydatne są również nagłówki takie jak Content-Type, Content-Length, Server, Retry-After i ewentualny request ID nadany przez usługę. Nie należy bezpośrednio utrwalać haseł, pełnych tokenów dostępowych ani kluczy API. Porównanie logu klienta z logiem serwera pozwala ustalić, czy żądanie dotarło do aplikacji, zostało odrzucone przez warstwę proxy, czy zakończyło się błędem wewnątrz endpointu.

Postępowanie przy powtarzających się błędach

Jeżeli serwer zwraca kod 4xx, ponawianie identycznego żądania zwykle nie rozwiązuje problemu. Najpierw trzeba poprawić dane wejściowe, uwierzytelnienie, uprawnienia, metodę albo adres zasobu. Dla kodu 429 należy uwzględnić ograniczenie liczby żądań i, jeżeli serwer udostępnia taki nagłówek, zastosować czas wskazany przez Retry-After. W przypadku kodów 502, 503 i 504 można rozważyć kontrolowane ponowienie, ale tylko z limitem prób, rosnącym odstępem między próbami i zabezpieczeniem przed wielokrotnym wykonaniem operacji nieidempotentnej.

Na laptopie lub komputerze PC warto sprawdzić kolejno połączenie sieciowe, rozwiązywanie DNS, dostępność właściwego portu, certyfikat TLS, ustawienia proxy oraz zaporę sieciową. Następnie można porównać zachowanie aplikacji z ręcznie wysłanym żądaniem testowym, zachowując tę samą metodę, adres, nagłówki i treść. Warszawskie Pogotowie Komputerowe zajmuje się profesjonalną naprawą laptopów, komputerów PC oraz ich podzespołów, a w przypadku problemu z aplikacją analizuje również zależności między systemem, konfiguracją sieciową i programem zgłaszającym błąd.