Każda aplikacji internetowych musi komunikować się z serwerem aby otrzymywać dane, dodawać nowe i aktualizować istniejące. Każda taka komunikacja musi być kontrolowana i sprawdzana pod kątem poprawności wykonania. Do tego celu pomagają nam tak zwane kody odpowiedzi, które występują w każdej wiadomości pochodzącej z serwera. Jednak jakie kody możemy dostać i jakie powinniśmy wysyłać pisząc aplikacje webowe?
Kody odpowiedzi dla zapytań HTTP zostały opisane w standardzie HTTP/1.1 i możecie o nich poczytać w standardzie RFC 7231 oraz innych, które dopisywały kolejne kody odpowiedzi. Zostały one podzielone na 5 grup, każda poświęcona innemu celowi. Rozróżniamy grupy:
Dziś chciałbym opisać pokrótce te najczęściej spotykane w aplikacjach internetowych, kiedy je wykorzystywać i jak obsłużyć po stronie aplikacji klienckiej.
Zaczniemy od rzeczy przyjemnych czyli kodów, które są związane z sukcesem naszej operacji.
Na pierwszy rzut będzie standardowy kod 200 OK, który jest najbardziej ogólny i oznacza, że wysłane zapytanie zakończyło się sukcesem. Dodatkowo jeśli zapytanie zakończyło się tym statusem oznacza to, że powinniśmy również otrzymać w odpowiedzi jakieś dane.
Kod odpowiedzi najczęściej kojarzony z operacją POST czyli stworzeniem zasobu po stronie serwera. Co istotne tą odpowiedź możemy wysłać dopiero po faktycznym stworzeniu zasobu. Powinniśmy także wysłać informację do klienta jak się dostać do nowo utworzonego elementu.
Serwer przyjął zapytanie od klienta, przetworzył ale nic nie zwraca w odpowiedzi.
Teraz już nie będzie tak fajnie bo kody 4xx oraz 5xx oznaczają, że coś się nie powiodło i należy na to jakoś zareagować. Błędy 4xx charakteryzują się tym, że winę najczęściej ponosi frontend więc i na niego spada konieczność znalezienia i poprawy błędu.
Błąd, który otrzymujemy kiedy serwer nie był w stanie przetworzyć naszego żądania. Może to być spowodowane tym, że nie wysyłamy tego co powinniśmy czyli np.: deklarujemy że wysyłamy JSON a tak naprawdę leci XML, albo wysyłamy JSON, który ma błędy i nie da się go przetworzyć. Bardzo często też widzę ten kod w odpowiedzi na wysłanie formularza, który ma niepoprawne dane np.: imię które zawiera cyfry ale do tego celu istnieje lepszy kod odpowiedzi.
Nazwa jest trochę pechowa, ponieważ ten kod błędu odnosi się do błędu autentykacji(uwierzytelnienia) a nie autoryzacji. Z racji tego, że te dwa pojęcia się mylą szybka powtórka:
I szybki przykład: Użytkownik może być uwierzytelniony w systemie i z niego korzystać ale jeśli nie ma roli admina to nie przejdzie autoryzacji by móc np.: obejrzeć logi z systemu.
Błąd ten może wystąpić w każdym zapytaniu do serwera i informuje, że w zapytaniu nie ma odpowiednich informacji o tym czy użytkownik jest zalogowany w systemie (może to być token JWT, odpowiednie cookie lub cokolwiek innego)
Tutaj jest miejsce dla drugiej sytuacji czyli jesteśmy uwierzytelnieni ale nie mamy dostępu do danej części systemu. Najczęściej pojawia się w systemach gdzie istnieje wiele ról, które posiadają odmienne dostępy do różnych części systemu np.: rola która zakazuje wstępu do ustawień, druga która pozwala na pobranie i wyświetlenie ale nie edycję oraz inna która może wszystko. Błąd ten może się pojawić jeśli logika w aplikacji klienckiej nie przewidziała jakiegoś przypadku i wpuściła użytkownika tam gdzie nie ma dostępu lub też użytkownik sam próbuje się tam dostać przez wpisanie odpowiedniego adresu URL
To czego szukamy nie istnieje na serwerze. Najczęściej się to odnosi to do sytuacji gdy chcemy pobrać pliki z serwera, pobrać informacje o nieistniejącym elemencie lub jak w przypadku stron statycznych wpisaniu niewłaściwego url’a.
Osobiście mój ulubiony kod z tej grupy ponieważ najczęściej jego wystąpienie jest winą backendu. Spotkamy go jeśli serwer zabronił pewnych operacji np.: ze względów bezpieczeństwa. Jest to również popularny błąd dla mechanizmu CORS jeśli backend nie zwrócił dozwolonych operacji w nagłówku Access-Control-Request-Method
To jest błąd, który według specyfikacji powinniśmy wykorzystywać dla błędów żądania, które są poprawne pod względem techniczym ale zawierają błędy w wartości.
I błędy, których nikt nie chce widzieć ponieważ oznaczają, że coś zepsuło po stronie serwera.
Błąd też oznacza, że serwer napotkał jakiś problem i nie może skończyć żądania. Może być spowodowany za dużą ilością żądań a więc przeciążeniem serwera, błędem w kodzie np.: próbowanie wyciągnięcia wartości z nulla, błędnie napisanym skrypcie lub też innym wyjątkiem, który nie został poprawnie złapany i obsłużony. Znalezienie przyczyny i naprawa takiego błędu może być utrudniona i zająć sporo czasu jeśli nie mamy odpowiednio tworzonych logów.
Z błędów, z którymi spotykam się najczęściej to będzie wszystko. Czy jest coś co byście dodali do tej listy? A możecie macie własne przemyślenia dotyczące kodów odpowiedzi HTTP? Zapraszam do komentowania i dzielenia się wpisem.
FSGeek