6.6 Hálózati és API hibák debuggolása

Áttekintő

Ha frontenden dolgozol és az adat nem jelenik meg, vagy backenden írsz API-t és a kliens nem kapja meg a választ, a hálózati réteg lesz az első gyanúsított. A legtöbb junior fejlesztő ilyenkor a kódot nézi – holott a válasz sokszor a kérés-válasz párosban van, nem a logikában.

Ez az alfejezet megtanítja, hogyan olvasd el, mit mond neked a hálózat: mit jelentenek a HTTP státuszkódok, hogyan dekódold az API-hívás eredményét, és milyen eszközökkel tudod izolálni, hogy a hiba a kérésben, a szerveren, vagy az adatban van-e.

Ez a fejezet azért számít az első munkahelyeden, mert a legtöbb napi munka tartalmaz API-hívást. Ha nem tudod elolvasni a hálózati forgalmat, minden hibakeresésed vakrepülés lesz.

Részletes leírás

HTTP státuszkódok – nem random számok

Minden HTTP válasz tartalmaz egy háromjegyű státuszkódot. Ezeket nem kell kívülről tudni, de az egyes csoportokat igen.

Kategória	Tartomány	Jelentés
2xx	200–299	Sikeres kérés
3xx	300–399	Átirányítás
4xx	400–499	Kliens hibája
5xx	500–599	Szerver hibája

A legfontosabb kódok, amiket naponta fogsz látni:

200 OK – minden rendben, válasz jött
201 Created – erőforrás létrejött (POST után tipikus)
204 No Content – sikeres, de nincs visszaadott tartalom (pl. DELETE után)
400 Bad Request – a kérés hibás, a szerver nem érti (pl. hiányzó mező, rossz formátum)
401 Unauthorized – nincs vagy érvénytelen hitelesítés
403 Forbidden – hitelesítés rendben, de nincs jogosultság
404 Not Found – az erőforrás nem létezik
422 Unprocessable Entity – a kérés szintaktikailag helyes, de szemantikailag nem (pl. érvénytelen email formátum, de a JSON struktúra jó volt)
500 Internal Server Error – valami elbukott a szerveren (nézd a szerver logokat)
502 Bad Gateway – a proxy nem kapta meg a választ a backendtől
503 Service Unavailable – a szerver nem elérhető (overload vagy karbantartás)

Kulcs különbség, amit sokan összekevernek:

401 vs 403: A 401-nél fogalmad sincs, ki kérdezi. A 403-nál tudod, ki kérdezi, de nem engedélyezett számára.
404 vs 400: A 404 azt jelenti, az URL nem létezik. A 400 azt, az URL létezik, de a kérés maga hibás.

Az API hibakeresés gondolkodásmódja: request → response → adat

Amikor egy API-hívás nem úgy viselkedik, ahogy kellene, három helyen lehet a hiba. Mindig ebben a sorrendben ellenőrizd:

1. Request (Kérés) – Egyáltalán jó kérést küldtem?

Helyes a metódus? (GET/POST/PUT/DELETE)
Helyes az URL? (typo, hiányzó útvonalparaméter, rossz verzió: /api/v1 vs /api/v2)
Megvannak a kötelező header-ek? (Content-Type: application/json, Authorization token)
Helyes a body formátuma? (JSON-e ahol kell, jó a struktúra?)

2. Response (Válasz) – Mit mondott vissza a szerver?

Mi a státuszkód?
Van response body? Mit tartalmaz?
Az error message informatív?

3. Adat – A válasz rendben van, de az adat más, mint vártam?

Jó mezők jönnek vissza?
Üres lista vs. null különbség
Típus eltérés (string jön, number kellene)

Browser DevTools – Network tab

Ha böngészőben futó applikációt debuggolsz, a DevTools Network tab a legjobb barátod.

Megnyitás: F12 → Network fül (vagy jobb klikk → Vizsgálat)

Amit látsz:

Az összes kérés listája (URL, metódus, státuszkód, méret, idő)
Szűrés típus szerint: XHR/Fetch (ezek az AJAX API-hívások), JS, CSS, Img

Egy kérés megvizsgálása:

Kattints rá → megnyílik a részletes nézet
Headers fül: request headers (mit küldtél), response headers (mit kaptál)
Payload fül (vagy Request Body): mit küldtél body-ban
Response fül: a nyers válasz tartalma
Preview fül: formázott JSON válasz (könnyebb olvasni)

Leggyakoribb hiba amit itt látni fogsz:

POST /api/users  →  400 Bad Request
Response: { "error": "email is required" }

Ez azonnal megmondja: a kérésből hiányzik az email mező.

Tipp: Ha az API hívás előtt navigálsz el az oldalról, a hívás eltűnhet a listából. Jelöld be a „Preserve log" opciót, hogy megmaradjanak.

curl – API hívás parancssorból

A curl parancssorból tud HTTP kéréseket küldeni. Azért hasznos, mert izolálni tudsz: ha curl-lel működik, de az applikációból nem, a hiba az appban van, nem az API-ban.

Alap GET kérés:

curl https://api.example.com/users

POST kérés JSON body-val:

curl -X POST https://api.example.com/users \
  -H "Content-Type: application/json" \
  -d '{"name": "Kovács Péter", "email": "peter@example.com"}'

Authentikált kérés Bearer tokennel:

curl https://api.example.com/me \
  -H "Authorization: Bearer eyJhbGci..."

Részletes kimenet (verbose) – mikor kell a header is:

curl -v https://api.example.com/users

A -v flag mutatja a teljes request-response párost, header-ekkel együtt. Hasznos, ha nem érted, mit küld a szerver vissza.

Válasz mentése fájlba:

curl https://api.example.com/export -o output.json

Postman és Insomnia – grafikus API kliens

Ha sok API kérést kell kipróbálni vagy dokumentálni, a grafikus kliensek kényelmesebbek a curl-nél.

Mit adnak:

Mentett kérések kollekciókba szervezve (nem kell újraírni minden kérést)
Környezetek (dev/staging/prod URL könnyen váltható)
Automatikusan formázott JSON válasz
Authentikáció kezelése GUI-ban
Tesztek írása (pl. ellenőrizd, hogy 200 jött vissza)

Mikor érdemes használni:

Amikor új API-t explorálsz (nem kell kódot írni)
Amikor valaki más API-ját integrálod és tesztelni kell az endpointokat
Amikor bug reporthoz reprodukálható példát akarsz mutatni

Mindkét eszköz ingyenes. Postman elterjedtebb, Insomnia nyílt forráskódú – a gondolkodásmód ugyanaz.

A CORS hiba – amit mindenki lát, kevesen értenek

Access to fetch at 'https://api.example.com/users' from origin 
'http://localhost:3000' has been blocked by CORS policy

Mi ez? A böngésző biztonsági mechanizmusa. Ha a frontend egy másik origin-ről (más domain, port, protokoll) próbál API-t hívni, a böngésző megkérdezi az API-t: „engedélyezed, hogy ez az origin elérjen téged?"

Fontos: A CORS hiba nem a frontenden oldódik meg. A szerveren kell beállítani, hogy elfogadja az adott origint. Ha te írtad a backended, adj hozzá CORS header-t. Ha külső API-t hívsz, proxy-n keresztül kell menni.

Amit keress a hibaüzenetben:

Melyik origin próbált hívni? (a te localhostad)
Melyik endpointot? (az URL)
Melyik fejléc hiányzik? (Access-Control-Allow-Origin)

Életszerű példák

Eset 1: „Nem jönnek be az adatok a dashboardra"

Júlia frontendesen dolgozik. A dashboard üres, pedig az API-nak adatot kellene visszaadnia. Első lépésként kinyitja a DevTools Network tabot, frissíti az oldalt, és megkeresi az API hívást.

Amit lát:

GET /api/dashboard/stats  →  401 Unauthorized

A válasz body:

{ "error": "Token expired" }

A hiba nem az adatban van, nem a logikában – a session lejárt. A megoldás: a token refresh logika hibás, vagy egyszerűen be kell jelentkezni újra. Júlia 5 perc alatt megtalálta, amit órákon át keresett volna a kódban.

Eset 2: „A szerver mindig 500-at dob"

Bence backendesen írt egy új API endpointot. A frontend kollégája jelzi: mindig 500-as hibát kap.

Bence megnyitja a szerver logot:

TypeError: Cannot read property 'id' of undefined
  at UserController.getProfile (user.controller.js:42)

A log azonnal megmutatja: a 42. sorban undefined-ot próbál olvasni, valószínűleg hiányzik egy null-check. A 500-as státuszkód csak azt mondta: „valami elromlott nálam" – a log adta meg a pontos helyet.

Tanulság: 5xx hibáknál mindig a szerver logot nézd, ne a frontend hibaüzenetét.

Eset 3: „curl-lel megy, appból nem"

Anna integrál egy fizetési API-t. curl-lel:

curl -X POST https://payment.api/charge \
  -H "Authorization: Bearer sk_test_abc123" \
  -H "Content-Type: application/json" \
  -d '{"amount": 1000, "currency": "HUF"}'
# Válasz: 200 OK, { "status": "success" }

Az appból ugyanez 401-et dob. Megvizsgálja a kérést DevTools-ban: az Authorization header hiányzik. Kiderül, hogy a token betöltése aszinkron, és a komponens a token megérkezése előtt küldi el a kérést. A hiba az appban volt, az API-ban nem.

Eset 4: „404, de az endpoint létezik"

Dávid meghív egy API-t:

GET /api/user/123/profil  →  404

Megnézi a dokumentációt – az endpoint /api/users/123/profile (users, többes szám; profile, angol helyesírással). Két typo volt az URL-ben. A 404 nem azt jelenti, a szerver hibás – az URL nem létezik. Mindig ellenőrizd az URL-t szóról szóra.

Példafeladat

Az alábbi szituáció alapján válaszolj a kérdésekre:

Szituáció: A frontend alkalmazás az alábbi kérést küldi:

POST /api/orders
Content-Type: application/json
Authorization: Bearer eyJhbGci...

{
  "product_id": 42,
  "quantity": "3"
}

A szerver válasza:

HTTP/1.1 422 Unprocessable Entity

{
  "error": "Validation failed",
  "details": [
    { "field": "quantity", "message": "must be an integer, got string" }
  ]
}

Kérdések:

A hiba a kliensen van vagy a szerveren? Hogyan tudod ezt a státuszkódból megállapítani?
Mit jelent pontosan a 422 státuszkód ebben a kontextusban?
Pontosan mi a hiba? Hogyan javítanád a kérést?
Ha a szerver 500-at adott volna vissza ugyanerre a kérésre, mit tennél első lépésként?
Hogyan ellenőriznéd curl-lel, hogy a javított kérés már működik-e?

Tesztfeladatok

1. kérdés

Melyik HTTP státuszkód jelzi, hogy a kérés szintaktikailag helyes volt, de az adatok validációja sikertelen (pl. az életkor negatív szám)?

A) 400 Bad Request
B) 401 Unauthorized
C) 422 Unprocessable Entity
D) 500 Internal Server Error

Helyes válasz: C
Magyarázat: A 400 általánosabb hibát jelez (pl. érvénytelen JSON, hiányzó kötelező mező szintaktikai szinten). A 422 pontosan arra való, amikor a struktúra helyes, de az adatok nem felelnek meg a validációs szabályoknak.

2. kérdés

Az alábbi hibák melyike van a kliensnek felróva és melyike a szervernek?

403 Forbidden
503 Service Unavailable
404 Not Found
502 Bad Gateway

A) Kliens: 1, 3 | Szerver: 2, 4
B) Kliens: 1, 2 | Szerver: 3, 4
C) Kliens: 3, 4 | Szerver: 1, 2
D) Mind kliens hiba

Helyes válasz: A
Magyarázat: A 4xx hibák kliens oldaliak (a kérés volt hibás vagy jogosulatlan), az 5xx hibák szerver oldaliak (a szerver nem tudta kiszolgálni a kérést).

3. kérdés

Mi a különbség a 401 és 403 státuszkód között?

A) 401: a felhasználó bejelentkezett, de nincs jogosultsága. 403: nincs bejelentkezve.
B) 401: nincs vagy érvénytelen hitelesítés. 403: hitelesítés rendben, de nincs jogosultság az adott erőforráshoz.
C) Nincs különbség, felváltva használhatók.
D) 401: REST API-ban használatos. 403: weboldalakon.

Helyes válasz: B
Magyarázat: A 401 (Unauthorized) azt jelenti: „nem tudom, ki vagy" – hiányzik vagy érvénytelen a token. A 403 (Forbidden) azt jelenti: „tudom, ki vagy, de ez neked nem engedélyezett."

4. kérdés

Böngészőben fejlesztesz, és az API-hívás nem jelenik meg a Network tabban. Mi lehet az oka?

A) A Network tab nem mutatja az XHR kéréseket, csak a HTML betöltést.
B) Az oldal navigáláskor törlődnek a kérések, és nincs bekapcsolva a „Preserve log" opció.
C) A DevTools csak HTTPS kéréseket mutat.
D) Az API hibája miatt a kérés el sem indul.

Helyes válasz: B
Magyarázat: Alapesetben a Network tab töröl minden kérést, ha navigálsz. A „Preserve log" bekapcsolásával megmaradnak az átirányítás, oldalbetöltés után is.

5. kérdés

Az alábbi curl parancsok közül melyik küld POST kérést JSON body-val és Authorization header-rel?

A) curl https://api.example.com/users -d '{"name":"test"}'
B) curl -X POST https://api.example.com/users -H "Content-Type: application/json" -H "Authorization: Bearer token123" -d '{"name":"test"}'
C) curl --post https://api.example.com/users --json '{"name":"test"}' --auth token123
D) curl https://api.example.com/users --method POST --body '{"name":"test"}' --token token123

Helyes válasz: B
Magyarázat: A -X POST adja meg a metódust, a -H flag-gel lehet header-eket hozzáadni (Content-Type és Authorization), a -d flag adja meg a body-t.

6. kérdés

Megírtál egy API hívást, amely curl-lel működik, de az alkalmazásodból mindig 401-et kap. Mi az első lépés a hibakeresésben?

A) Újraírni az egész hitelesítési modult, mert biztosan ott a hiba.
B) Megnézni a DevTools Network tabban az alkalmazásból induló kérés headers-ét, és összehasonlítani a curl parancsban lévővel.
C) Törölni a böngésző cache-t, mert az okozza a problémát.
D) A curl és az alkalmazás nem tud ugyanolyan kérést küldeni, tehát ez normális.

Helyes válasz: B
Magyarázat: Ha curl-lel megy, az API biztosan helyes. A különbség az applikáció kérésében van. Össze kell hasonlítani a két kérést – leggyakrabban a hiányzó vagy rosszul formázott Authorization header az ok.

7. kérdés

Mi az oka a CORS hibának, és hol kell megoldani?

A) A frontend kódban elírtak egy URL-t. Megoldás: javítani az URL-t a frontenden.
B) A böngésző blokkolja a másik originről érkező kéréseket, ha a szerver nem engedélyezi. Megoldás: a szerveren kell beállítani a CORS engedélyezést.
C) A szerver nem fogadja a JSON formátumot. Megoldás: XML-ben kell küldeni az adatot.
D) CORS hibát csak HTTPS esetén kaphatunk. Megoldás: HTTP-re visszaváltani fejlesztés közben.

Helyes válasz: B
Magyarázat: A CORS (Cross-Origin Resource Sharing) egy böngésző-szintű biztonsági mechanizmus. A frontendről nem oldható meg – a backendet kell konfigurálni, hogy a megfelelő Access-Control-Allow-Origin header-t adja vissza.

8. kérdés

Az alábbi szituációk közül melyiknél érdemes Postmant vagy Insomniát curl helyett használni?

Gyorsan ellenőrizni, visszaad-e egy endpoint 200-at
Egy új, ismeretlen API explorálása, sok endpointtal
Automatizált tesztpipeline-ban API-t hívni
Csapattal megosztani a tesztelt API kérések kollekciójátAt

A) Csak 1
B) 2 és 4
C) 1 és 3
D) Mind a négy esetben curl jobb

Helyes válasz: B
Magyarázat: A Postman/Insomnia erőssége a szervezett kollekciók és a vizuális explorer – ismeretlen API feltérképezéséhez és csapatmegosztáshoz ideális. Gyors egyszeri ellenőrzéshez a curl gyorsabb. Automatizált pipeline-ban a curl (vagy dedikált tool) jobb, mert nem igényel GUI-t.

9. kérdés

A szerver 500 Internal Server Error hibával válaszol. Mi a leghasznosabb következő lépés?

A) Újraküldeni a kérést, hátha magától megjavul.
B) Megvizsgálni a szerver oldali logokat, ahol a stack trace és a tényleges hiba látható.
C) Megnézni a frontend konzolban a hibaüzenetet, az fog mindent megmagyarázni.
D) A 500-as hiba mindig hálózati probléma, meg kell várni, amíg helyreáll.

Helyes válasz: B
Magyarázat: Az 5xx hibák szerver oldaliak. A frontend csak annyit tud, hogy a szerver hibát dobott. A pontos ok – stack trace, érintett sor, hibaüzenet – a szerver logokban van. Mindig ott kell keresni 500-as hiba esetén.

10. kérdés

Egy API endpoint 204 No Content státuszkóddal válaszol, de a frontendben a következő kódrészlet futtatásakor hiba lép fel:

const response = await fetch('/api/items/42', { method: 'DELETE' });
const data = await response.json();  // Hiba itt!
console.log(data);

Mi okozza a hibát?

A) A DELETE metódus nem engedélyezett ezen az endpointon.
B) A 204 No Content válaszhoz nem tartozik body, ezért a .json() parsing sikertelen.
C) A fetch API nem tud DELETE kérést küldeni.
D) Az endpoint URL hibás.

Helyes válasz: B
Magyarázat: A 204 No Content azt jelenti: sikeres volt a kérés, de a szerver szándékosan nem küld vissza semmit (ez DELETE után tipikus). Ha üres body-ra próbálod meghívni a .json()-t, az parsing hibát dob, mert nincs mit feldolgozni. Ellenőrizni kell a státuszkódot, mielőtt a body-t parsolod.