HTTP protokol státusz kódok

A HTTP protokoll státuszkódjai a kliens és a szerver közötti kommunikáció során visszaadott válaszüzenetek, amelyek jelzik a kérések eredményét. Ezeket a státuszkódokat több csoportba sorolhatjuk.

1xx – Információs válaszok

100 Continue – A szerver elfogadta a kérést, a kliens folytathatja.
101 Switching Protocols – A szerver elfogadta a protokollváltást.

Teszt eset:
Küldj egy Expect: 100-continue fejlécet egy nagy POST kérés előtt.

2xx – Sikeres válaszok

200 OK – A kérés sikeresen teljesült.
201 Created – Az erőforrás sikeresen létrejött.
204 No Content – A kérés sikeres, de nincs visszatérő adat.

Teszt eset:
Küldj egy GET kérést egy meglévő erőforrásra, és ellenőrizd, hogy 200 OK választ kapsz.

3xx – Átirányítások

301 Moved Permanently – Az erőforrás véglegesen más helyre került.
302 Found – Az erőforrás ideiglenesen elérhető másik URL-en.
304 Not Modified – A kliens cache-elt verziója még érvényes.

Teszt eset:
Nyiss meg egy régi URL-t, amely 301 átirányítást ad egy új címre.

4xx – Klienshibák

400 Bad Request – A kérés hibás vagy hiányos.
401 Unauthorized – Hitelesítés szükséges.
403 Forbidden – A hozzáférés megtagadva.
404 Not Found – Az erőforrás nem található.

Teszt eset:
Próbálj meg egy nem létező oldalra kérést küldeni, és ellenőrizd, hogy 404-et kapsz.

5xx – Szerverhibák

500 Internal Server Error – Általános szerverhiba.
502 Bad Gateway – A proxy szerver hibás választ kapott.
503 Service Unavailable – A szerver túlterhelt vagy karbantartás alatt áll.

Teszt eset:
Állítsd le a szervered, majd küldj egy kérést, hogy lásd a 503 választ.

Összefoglaló táblázat

Kód	Kategória	Jelentés
100	Információs	Continue
101	Információs	Switching Protocols
200	Sikeres	OK
201	Sikeres	Created
204	Sikeres	No Content
301	Átirányítás	Moved Permanently
302	Átirányítás	Found
304	Átirányítás	Not Modified
400	Klienshiba	Bad Request
401	Klienshiba	Unauthorized
403	Klienshiba	Forbidden
404	Klienshiba	Not Found
500	Szerverhiba	Internal Server Error
502	Szerverhiba	Bad Gateway
503	Szerverhiba	Service Unavailable

HTTP protokol alapok

1. A HTTP protokoll működése

A HTTP (Hypertext Transfer Protocol) egy kérés-válasz alapú protokoll, amelyet a kliens (pl. böngésző) és a szerver közötti kommunikációra használnak.

1.1. Hogyan épül fel egy HTTP kérés?

Egy HTTP kérés négy fő részből áll:

Kérés metódus (Method) – Pl. GET, POST, PUT, DELETE stb.
URL (Uniform Resource Locator) – A célcím, amit a kliens elérni szeretne.
Fejlécmezők (Headers) – Extra információk a szervernek (pl. User-Agent, Accept, Authorization).
Törzs (Body) – Egyes metódusoknál (pl. POST, PUT) itt található a kérés tartalma.

Példa egy HTTP kérésre (GET)

-- vbnet

GET /index.html HTTP/1.1
Host: www.example.com
User-Agent: Mozilla/5.0
Accept: text/html

Ez azt jelenti, hogy a kliens a www.example.com szerver index.html fájlját kéri, HTML formátumban.

1.2. Hogyan épül fel egy HTTP válasz?

A szerver egy HTTP választ küld vissza, amely három fő részből áll:

Státuszsor (Status Line) – Tartalmazza a HTTP verziót, a státuszkódot és annak rövid jelentését.
Fejlécmezők (Headers) – Olyan információkat tartalmaz, mint a tartalom típusa (Content-Type), hossz (Content-Length), és egyéb metaadatok.
Törzs (Body) – Az erőforrás tartalma (pl. egy HTML oldal).

Példa egy HTTP válaszra

--- php-template

HTTP/1.1 200 OK
Date: Sat, 08 Mar 2025 12:00:00 GMT
Server: Apache/2.4.41
Content-Type: text/html
Content-Length: 1234

<html>
    <body>
        <h1>Üdvözlünk!</h1>
    </body>
</html>

Itt a státuszsorban a 200 OK jelzi, hogy a kérés sikeresen teljesült.

1.3. HTTP Metódusok és Idempotencia

A HTTP metódusok meghatározzák, hogy mit szeretne a kliens tenni az adott erőforrással:

Metódus	Leírás	Idempotens?	Biztonságos?
GET	Erőforrás lekérése	✅ Igen	✅ Igen
POST	Új erőforrás létrehozása	❌ Nem	❌ Nem
PUT	Erőforrás módosítása vagy létrehozása	✅ Igen	❌ Nem
DELETE	Erőforrás törlése	✅ Igen	❌ Nem

Idempotens: Ha többször végrehajtjuk a kérést, az ugyanazt az eredményt adja.
Biztonságos: Nem módosítja az állapotot a szerveren.

👉 Példa: Ha egy DELETE /users/123 kérést küldesz egy szervernek, az törli a felhasználót. Ha többször küldöd el, az eredmény ugyanaz (mert a felhasználó már törölve lett), ezért idempotens.

Státuszkódok mélyebb elemzése

A HTTP státuszkódok a szerver válaszának állapotát jelzik. Az alapszintű csoportosításon túl érdemes megvizsgálni a státuszkódok közötti összefüggéseket, speciális használati eseteket és gyakorlati példákat.

2.1. Státuszkódok főbb csoportjai és jelentésük

A státuszkódok öt fő kategóriába sorolhatók:

Kategória	Kódok tartománya	Jelentés
1xx (Információs)	100–199	A kérés feldolgozás alatt van
2xx (Sikeres)	200–299	A kérés sikeresen teljesült
3xx (Átirányítás)	300–399	A kért erőforrás más helyen található
4xx (Klienshiba)	400–499	A kliens hibás kérést küldött
5xx (Szerverhiba)	500–599	A szerver hibát észlelt a kérés feldolgozásakor

2.2. Részletes státuszkód elemzés példákkal

2.2.1. 1xx – Információs válaszok

Ezek a kódok ritkán fordulnak elő a mindennapi webfejlesztés során.

Kód	Jelentés	Példa felhasználás
100 Continue	A szerver jelezte, hogy folytatható a kérés.	Nagy `POST` kérések esetén használják, hogy a kliens előbb lekérje az engedélyt.
101 Switching Protocols	A szerver egy másik protokollra vált.	Pl. ha a kliens `Upgrade: websocket` fejléccel kéri a WebSocket kapcsolatot.

2.2.2. 2xx – Sikeres válaszok

A szerver sikeresen feldolgozta a kérést.

Kód	Jelentés	Példa
200 OK	A kérés sikeres.	Egy HTML oldal sikeres lekérése `GET /index.html` segítségével.
201 Created	Az erőforrás sikeresen létrejött.	Egy új felhasználó létrehozása `POST /users` során.
204 No Content	Sikeres kérés, de nincs visszatérő adat.	Egy rekord sikeres törlése `DELETE /users/123`, ahol nincs szükség válaszra.

2.2.3. 3xx – Átirányítások

A kért erőforrás elérhető, de más helyen.

Kód	Jelentés	Példa
301 Moved Permanently	Az URL véglegesen megváltozott.	Weboldal domainváltás (`example.com` → `newsite.com`).
302 Found	Ideiglenes átirányítás.	Egy bejelentkezési oldal, amely visszairányít a főoldalra.
304 Not Modified	A kliens cache-elt verziója még érvényes.	Böngésző gyorsítótárazás (`If-Modified-Since`).

2.2.4. 4xx – Klienshibák

A kéréssel valami nem stimmel.

Kód	Jelentés	Példa
400 Bad Request	Érvénytelen kérés.	Hiányzó vagy rosszul formázott JSON egy API-kérésben.
401 Unauthorized	Hitelesítés szükséges.	API-tokennel védett erőforrás lekérése engedély nélkül.
403 Forbidden	A kérés nem engedélyezett.	Egy admin felülethez való hozzáférés, ha nincs megfelelő jogosultság.
404 Not Found	Az erőforrás nem található.	Nem létező oldal lekérése (`GET /missing-page`).

2.2.5. 5xx – Szerverhibák

A szerver oldalon hiba történt.

Kód	Jelentés	Példa
500 Internal Server Error	Általános szerverhiba.	Hibás adatbázislekérdezés vagy nem kezelt kivétel.
502 Bad Gateway	A proxy szerver hibás választ kapott.	Nginx vagy más proxy rossz backend választ kap.
503 Service Unavailable	A szerver túlterhelt vagy karbantartás alatt áll.	Weboldal karbantartás miatt nem elérhető.

2.3. Mikor melyik státuszkódot érdemes használni?

Nézzünk néhány gyakorlati forgatókönyvet:

Felhasználó regisztráció
- Sikeres: 201 Created
- Hiányzó adatok: 400 Bad Request
- Már létező email cím: 409 Conflict
Bejelentkezés
- Sikeres: 200 OK
- Hibás jelszó: 401 Unauthorized
- Tiltott felhasználó: 403 Forbidden
Adatlekérés API-ból
- Sikeres válasz: 200 OK
- Cache-elt adat (nem frissült): 304 Not Modified
- Nincs jogosultság: 403 Forbidden
- Nem létező adat: 404 Not Found

Cache és státuszkódok kapcsolata

A HTTP gyorsítótárazás (cache) célja, hogy csökkentse a szerver terhelését és gyorsítsa az adatok betöltését. Ezt az ügyfél (böngésző, proxy) és a szerver közötti státuszkódok és fejlécmezők vezérlik.

3.1. Miért fontos a cache?

Csökkenti a szerver terhelését és válaszidőt.
Kevesebb sávszélességet fogyaszt, mivel nem kell újra letölteni az azonos adatokat.
Javítja a felhasználói élményt, mert gyorsabban tölt be az oldal.

3.2. Cache és státuszkódok összefüggése

Státuszkód	Jelentés	Cache-elhető?
200 OK	Normál válasz.	✅ Igen, ha `Cache-Control` engedi.
301 Moved Permanently	Végleges átirányítás.	✅ Igen, hosszú ideig.
302 Found	Ideiglenes átirányítás.	❌ Nem ajánlott.
304 Not Modified	A kliens gyorsítótárazott verziója érvényes.	✅ Nem töltődik le újra, csak frissül az érvényesség.
404 Not Found	Erőforrás nem található.	❌ Nem ajánlott.
410 Gone	Az erőforrás véglegesen eltűnt.	✅ Igen, de korlátozott ideig.

3.3. Fejlécek, amelyek befolyásolják a cache viselkedését

1. Cache-Control (Modern megoldás)

A szerver ezt a fejlécet küldi a válaszban, hogy meghatározza, hogyan kell a kliensnek kezelnie a gyorsítótárazást.

Példák:

Cache-Control: no-cache → A kliens mindig kérjen friss verziót a szervertől.
Cache-Control: no-store → Semmilyen adatot nem szabad gyorsítótárazni.
Cache-Control: max-age=3600 → Az adat 1 óráig érvényes.

📌 Gyakorlati példa:

--arduino

HTTP/1.1 200 OK
Cache-Control: max-age=86400

→ Az adat egy napig (86400 másodpercig) tárolható a gyorsítótárban.

2. ETag és Last-Modified (Validációs mechanizmusok)

Ezek az értékek segítenek a böngészőnek eldönteni, hogy a gyorsítótárazott verzió még érvényes-e.

ETag: Egy egyedi azonosító az erőforrás változatához.
Last-Modified: Az erőforrás utolsó módosításának dátuma.

Példa kérés, ahol a böngésző ellenőrzi a változást:

--- sql

GET /style.css HTTP/1.1
If-None-Match: "abc123"
If-Modified-Since: Wed, 06 Mar 2025 12:00:00 GMT

Ha az adat nem változott, a szerver ezt válaszolja:

--mathematica

HTTP/1.1 304 Not Modified

👉 Eredmény: A kliens nem tölti le újra az adatot, csak a meglévő verziót használja.

3.4. Cache implementáció különböző helyeken

Böngésző cache
- A böngésző tárolja a letöltött fájlokat (CSS, JS, képek).
- Cache-Control és ETag segítségével dönti el, hogy újra kell-e tölteni.
Proxy cache (CDN-ek, pl. Cloudflare, Akamai)
- Segítenek az erőforrásokat a felhasználókhoz közelebb tárolni.
- Gyakran használnak hosszabb max-age értékeket.
Szerveroldali cache (pl. Redis, Memcached)
- A dinamikus lekérdezések eredményeit gyorsítótárazza, hogy csökkentse az adatbázis terhelését.

3.5. Teszt esetek

Teszteld a böngésző cache viselkedését
- Nyiss meg egy oldalt, majd frissítsd (F5 vs. Ctrl+F5).
- Nézd meg a Network fülön, hogy van-e 304 Not Modified.
Próbáld ki a Cache-Control fejlécet
- Hozz létre egy HTML fájlt, és állíts be Cache-Control: no-cache fejlécet.
- Nézd meg, hogy a böngésző mindig lekéri-e újra.
ETag teszt

Küldj egy If-None-Match kérést Postmanből egy API végpontra.

OpenAPI és HTTP státuszkódok

Az OpenAPI egy szabvány az API-k dokumentálására és specifikációjára. A HTTP státuszkódok szerepe kulcsfontosságú az API válaszok leírásában, segítve a fejlesztőket és klienseket a megfelelő válaszok kezelésében.

4.1. OpenAPI és HTTP státuszkódok kapcsolata

Az OpenAPI definícióban a responses szekcióban határozzuk meg a lehetséges státuszkódokat és azokhoz tartozó válaszokat.

Egyszerű példa egy OpenAPI válaszra:

---yaml

paths:
  /users/{id}:
    get:
      summary: Felhasználó lekérése
      responses:
        "200":
          description: Sikeres válasz
          content:
            application/json:
              schema:
                $ref: "#/components/schemas/User"
        "404":
          description: A felhasználó nem található
        "500":
          description: Szerverhiba

Itt a következő státuszkódokat definiáljuk:

200 OK – Sikeres válasz, JSON formátumban adja vissza az adatot.
404 Not Found – Ha a felhasználó nem létezik.
500 Internal Server Error – Ha valamilyen szerverhiba történt.

4.2. OpenAPI válaszok típusai és példák

Az OpenAPI lehetővé teszi különböző státuszkódok dokumentálását JSON és más formátumokban.

1. Sikeres válasz JSON adattal

---yaml

responses:
  "200":
    description: Sikeres válasz
    content:
      application/json:
        schema:
          type: object
          properties:
            id:
              type: integer
            name:
              type: string
        example:
          id: 123
          name: "John Doe"

👉 Eredmény: A kliens ezt kapja vissza JSON formátumban.

2. 400-as hiba válasz validációs hibákkal

--yaml

responses:
  "400":
    description: Rossz kérés (hiányzó vagy hibás adatok)
    content:
      application/json:
        schema:
          type: object
          properties:
            error:
              type: string
        example:
          error: "A név mező kötelező."

👉 Eredmény: Ha a kliens rossz JSON-t küld, ezt kapja vissza.

3. 401 – Hitelesítés szükséges

--yaml

responses:
  "401":
    description: Nem hitelesített hozzáférés
    headers:
      WWW-Authenticate:
        description: "Basic realm='User Area'"
    content:
      application/json:
        example:
          error: "Nem megfelelő API token."

👉 Eredmény: Ha a kliens helytelen API kulcsot használ, ezt a választ kapja.

4.3. OpenAPI státuszkódok és dokumentációs ajánlások

Amikor API-t tervezünk, érdemes az alábbi irányelveket követni:

Mindig egyértelmű státuszkódokat adj meg. (200, 201, 204, 400, 404, 500)
Ne küldj 200 OK státuszt, ha hiba történt! (pl. 404 helyett 200 egy {"error": "not found"} üzenettel félrevezető lehet)
Használj példákat (example) a dokumentációban.
Adj részletes hibaüzeneteket, hogy a kliens tudja, mit kell javítani.

4.4. Tesztelés OpenAPI és státuszkódok esetén

Swagger UI / Redoc
- Használj Swagger UI-t, hogy ellenőrizd az API dokumentációdat.
- A responses szekcióban nézd meg, hogy a státuszkódok és válaszok megfelelőek-e.
Postman / cURL tesztek
- Küldj helyes és helytelen kéréseket, és figyeld meg a válaszokat (200, 400, 401, 404).
- Példa cURL paranccsal:
```
--sh

curl -X GET "https://api.example.com/users/123" -H "Authorization: Bearer INVALID_TOKEN"
```
  👉 Elvárt válasz: 401 Unauthorized

4.5. Összefoglalás

Az OpenAPI a státuszkódok segítségével egyértelműen dokumentálja az API válaszait.
Az API teszteléséhez használj Swagger UI-t, Postmant vagy cURL-t.
Mindig egyértelmű és pontos válaszokat küldj, hogy a kliens hatékonyan kezelhesse az API-t.

Gyakorlati hibakeresés és HTTP státuszkódok használata

A helyes státuszkódok alkalmazása és a hatékony hibakeresés kulcsfontosságú az API-k fejlesztésében és karbantartásában. Ebben a részben bemutatjuk a státuszkódok gyakorlati használatát, a hibakeresés módszereit és tesztelési technikákat.

5.1. A megfelelő státuszkódok kiválasztása

Sok fejlesztő elköveti azt a hibát, hogy helytelen státuszkódokat használ. Íme néhány gyakori hiba és a helyes megoldás:

Hibás megoldás	Helyes megoldás	Magyarázat
`200 OK` minden válaszra	`201 Created` új erőforrás létrehozásakor	Az új rekord létrehozása külön esemény.
`500 Internal Server Error` minden hibára	`400 Bad Request` érvénytelen bemenet esetén	A 400-as hiba egyértelműbb a kliens számára.
`200 OK` ha nincs találat	`404 Not Found` ha az adat nem létezik	A `404` egyértelműbb, hogy az erőforrás nem létezik.

5.2. Hibakeresési technikák API fejlesztés közben

Ha egy API nem működik megfelelően, a következő lépésekkel hatékonyan szűrheted ki a hibákat:

1. Ellenőrizd a válasz státuszkódját

Használj Postman, cURL vagy Swagger UI tesztelésre.

✅ Példa helyes kérésre és válaszra:

---sh

curl -X GET "https://api.example.com/users/123"

📌 Válasz:

--json

{
  "id": 123,
  "name": "John Doe"
}

Státuszkód: 200 OK – Minden rendben.

❌ Példa hibás kérésre:

--sh

curl -X GET "https://api.example.com/users/9999"

📌 Válasz:

--json

{
  "error": "User not found"
}

Státuszkód: 404 Not Found – A felhasználó nem létezik.

2. Nézd meg a HTTP fejléceket

A fejlécek segítenek az API működésének ellenőrzésében.

📌 Példa:

--sh

curl -I "https://api.example.com/users/123"

Válasz:

--pgsql

HTTP/1.1 200 OK
Content-Type: application/json
Cache-Control: no-cache

👉 Tipp: Ha a válasz Cache-Control: no-cache, az API mindig új adatokat küld.

3. Naplózás és monitoring

Ha egy API hibát dob (500 Internal Server Error), érdemes logolni a problémát.

📌 Példa Python Flask API hibakezelésre:

---python

from flask import Flask, jsonify

app = Flask(__name__)

@app.route("/user/<int:user_id>")
def get_user(user_id):
    try:
        if user_id != 123:
            return jsonify({"error": "User not found"}), 404
        return jsonify({"id": 123, "name": "John Doe"}), 200
    except Exception as e:
        app.logger.error(f"Hiba történt: {str(e)}")
        return jsonify({"error": "Internal Server Error"}), 500

👉 Tipp: A logger.error segít megtalálni a pontos hibát.

5.3. Teszt esetek az API státuszkódokhoz

Egy jól megtervezett API tesztelése kulcsfontosságú. Íme néhány alapvető teszteset:

Teszt neve	Kérés típusa	Várt státuszkód	Magyarázat
Sikeres lekérés	`GET /users/123`	`200 OK`	Létező felhasználó lekérése
Nem létező adat	`GET /users/9999`	`404 Not Found`	Ha az adat nem létezik
Érvénytelen kérés	`POST /users` hiányzó adatokkal	`400 Bad Request`	Hibás bemenet esetén
Új adat létrehozása	`POST /users` helyes adatokkal	`201 Created`	Sikeres bejegyzés létrehozása
Hitelesítés szükséges	`GET /admin` hitelesítés nélkül	`401 Unauthorized`	Ha nincs API kulcs

5.4. Összefoglalás

Mindig a megfelelő státuszkódot használd (200, 201, 400, 401, 404, 500).
Használj Postman, cURL és naplózást a hibakereséshez.
Implementálj részletes hibaüzeneteket, hogy a fejlesztők és a kliens értsék a problémát.
Teszteld az API-t különböző esetekkel, hogy biztosítsd a helyes működést.

IT, BI, DWH, DM, AI

HTTP protokol státusz kódok

HTTP protokol státusz kódok

1xx – Információs válaszok

2xx – Sikeres válaszok

3xx – Átirányítások

4xx – Klienshibák

5xx – Szerverhibák

Összefoglaló táblázat

HTTP protokol alapok

1. A HTTP protokoll működése

1.1. Hogyan épül fel egy HTTP kérés?

Példa egy HTTP kérésre (GET)

1.2. Hogyan épül fel egy HTTP válasz?

Példa egy HTTP válaszra

1.3. HTTP Metódusok és Idempotencia

Státuszkódok mélyebb elemzése

2.1. Státuszkódok főbb csoportjai és jelentésük

2.2. Részletes státuszkód elemzés példákkal

2.2.1. 1xx – Információs válaszok

2.2.2. 2xx – Sikeres válaszok

2.2.3. 3xx – Átirányítások

2.2.4. 4xx – Klienshibák

2.2.5. 5xx – Szerverhibák

2.3. Mikor melyik státuszkódot érdemes használni?

Cache és státuszkódok kapcsolata

3.1. Miért fontos a cache?

3.2. Cache és státuszkódok összefüggése

3.3. Fejlécek, amelyek befolyásolják a cache viselkedését

1. Cache-Control (Modern megoldás)

2. ETag és Last-Modified (Validációs mechanizmusok)

3.4. Cache implementáció különböző helyeken

3.5. Teszt esetek

OpenAPI és HTTP státuszkódok

4.1. OpenAPI és HTTP státuszkódok kapcsolata

4.2. OpenAPI válaszok típusai és példák

1. Sikeres válasz JSON adattal

2. 400-as hiba válasz validációs hibákkal

3. 401 – Hitelesítés szükséges

4.3. OpenAPI státuszkódok és dokumentációs ajánlások

4.4. Tesztelés OpenAPI és státuszkódok esetén

4.5. Összefoglalás

Gyakorlati hibakeresés és HTTP státuszkódok használata

5.1. A megfelelő státuszkódok kiválasztása

5.2. Hibakeresési technikák API fejlesztés közben

1. Ellenőrizd a válasz státuszkódját

2. Nézd meg a HTTP fejléceket

3. Naplózás és monitoring

5.3. Teszt esetek az API státuszkódokhoz

5.4. Összefoglalás

Megjegyzések

Megjegyzés küldése