← 7. Systems thinking – A nagy kép

7.2 HTTP és REST API alapok fejlesztő szemmel

Áttekintő

Fejlesztőként szinte minden nap találkozol HTTP kérésekkel és REST API-kkal – akár a frontend küldi őket, akár a backend fogadja, akár egy külső szolgáltatást hívsz meg. Mégis sokan nem értik pontosan, mi történik a motorháztető alatt.

Ez az alfejezet nem hálózati protokollok mélyreható tárgyalása. A cél az, hogy ne legyen fekete doboz számodra az API-kommunikáció: tudd, melyik HTTP metódust mikor kell használni, hogyan épül fel egy kérés és válasz, és mit jelent az, hogy egy API "RESTful". Ez a tudás napi szinten használható – interjúkon, code review-kon és hibakeresésnél egyaránt.

Miért számít ez az állásinterjún? Szinte minden junior interjún felmerül valamilyen formában a HTTP / REST kérdés. "Mi a különbség a GET és POST között?" vagy "Milyen státuszkódot ad vissza egy sikeres létrehozás?" – ezeket elvárják.

Miért számít production környezetben? Ha rossz HTTP metódust használsz, caching-problémákba, security-résekbe vagy meglepő viselkedésbe futsz. Ha nem érted a státuszkódokat, nem tudsz jó hibakezelést írni.

---

Részletes leírás

Mi az a HTTP?

A HTTP (HyperText Transfer Protocol) az internetes kommunikáció alapja. Minden alkalommal, amikor a böngésző megnyit egy oldalt, vagy az alkalmazásod adatot küld egy szerverre, HTTP-n keresztül zajlik a kommunikáció.

A HTTP kérés-válasz modellen alapszik:

• A kliens (böngésző, mobilapp, backend service) küld egy kérést (request)
• A szerver visszaküld egy választ (response)

Ez az egész – semmi mágikus.

---

HTTP metódusok – melyik mire való?

A HTTP metódus (más néven "ige") megmondja a szervernek, mit szeretnél csinálni. Öt metódust kell biztosan ismerned:

Fontos különbség – PUT vs. PATCH:

PUT esetén az egész erőforrást elküldöd. Ha valamit nem adsz meg, felülírja (vagy törli) azt a mezőt.
PATCH esetén csak a változtatni kívánt mezőket küldöd.

// PUT – felülírja az egész objektumot
PUT /users/42
{ "name": "Kovács Péter", "email": "peter@example.com", "role": "admin" }

// PATCH – csak az emailt változtatja
PATCH /users/42
{ "email": "peter.kovacs@example.com" }

GET nem módosít adatot. Ez nem csak konvenció – ha valaki cache-eli a GET kéréseket (és ezt sokan teszik), akkor a módosítás nem fog lefutni, vagy épp kétszer fut le. A GET idempotens és biztonságos legyen: futtathatod akárhányszor, nem változtat semmit.

---

URL struktúra – hogyan épül fel egy API végpont?

https://api.example.com/v1/users/42/posts?status=published&limit=10

RESTful URL-ek szabályai:

• Erőforrás neveket főnévként írd, nem igékkel: /users nem /getUsers
• Az ID az URL-ben legyen: /users/42 nem ?id=42
• Hierarchia jelzi a kapcsolatot: /users/42/posts = 42-es felhasználó posztjai

---

Request felépítése

Egy HTTP kérés három részből áll:

1. Sor (Request line):

GET /users/42 HTTP/1.1

2. Fejlécek (Headers):

Host: api.example.com
Authorization: Bearer eyJhbGci...
Content-Type: application/json
Accept: application/json

A legfontosabb headerek:

• Content-Type: milyen formátumban küldöd a body-t
• Authorization: hogyan azonosítod magad
• Accept: milyen formátumú választ vársz

3. Törzs (Body): Csak POST, PUT, PATCH kéréseknél van. GET-nél nincs body.

{
  "name": "Kovács Péter",
  "email": "peter@example.com"
}

---

Response felépítése

A szerver válasza szintén headerekből és body-ból áll, plusz van egy státuszkód:

HTTP/1.1 201 Created
Content-Type: application/json

{
  "id": 42,
  "name": "Kovács Péter",
  "email": "peter@example.com",
  "created_at": "2026-04-30T10:00:00Z"
}

---

Státuszkódok – a legfontosabbak

A státuszkód megmondja, mi történt a kéréseddel. Három számjegyű szám, az első jelzi a kategóriát:

2xx – Siker

3xx – Átirányítás

4xx – Klienshiba (te rontottad el)

5xx – Szerverhiba (a szerver rontotta el)

401 vs. 403 – ez előkerül interjúkon:

• 401: "Nem tudom, ki vagy" – nincs autentikáció
• 403: "Tudom, ki vagy, de nem engedem" – nincs jogosultság

---

JSON mint adatcsere formátum

A REST API-k többsége JSON-t (JavaScript Object Notation) használ az adatcserére. Szinte minden modern programozási nyelvből egyszerűen olvasható és írható.

{
  "id": 42,
  "name": "Kovács Péter",
  "email": "peter@example.com",
  "is_active": true,
  "score": 9.5,
  "tags": ["backend", "python"],
  "address": null
}

JSON alapszabályok:

• Kulcsok mindig idézőjelben: "name" nem name
• Értékek típusai: string, number, boolean (true/false), array, object, null
• Utolsó elem után nincs vessző (trailing comma hibát okoz)

---

RESTful elvek alapszinten

A REST (Representational State Transfer) nem egy protokoll, hanem egy tervezési elvrendszer. Nem kell minden elvét fejből tudni, de a lényeget érdemes érteni:

1. Erőforrás-orientált Az URL erőforrást jelöl, nem műveletet. /users erőforrás, GET /users a lekérés művelete.

2. Állapotmentes (stateless) Minden kérés önálló – a szerver nem emlékezik az előző kérésedre. Az azonosításhoz szükséges adatot (pl. token) te küldöd minden kérésben.

3. Egységes interfész Mindenki ugyanolyan módon kommunikál az API-val – nincs "speciális" endpoint csak neked.

Gyakorlatban: Egy "elég RESTful" API:

• Megfelelő HTTP metódusokat használ
• Értelmesen adja vissza a státuszkódokat
• JSON-t küld és fogad
• Az URL erőforrást jelöl, nem műveletet

---

Életszerű példák

Példa 1: CRUD API tervezése blogposztokhoz

GET    /posts          → Összes poszt listája
GET    /posts/15       → 15-ös poszt részletei
POST   /posts          → Új poszt létrehozása
PUT    /posts/15       → 15-ös poszt teljes felülírása
PATCH  /posts/15       → 15-ös poszt részleges módosítása
DELETE /posts/15       → 15-ös poszt törlése

Mi jön vissza?

POST /posts → 201 Created + az új poszt adatai (id-val együtt)
GET /posts/999 → 404 Not Found (ha nem létezik)
DELETE /posts/15 → 204 No Content (ha sikerült)

---

Példa 2: Frontend-backend kommunikáció valóságban

Egy React frontend feltölti a felhasználó profilképét:

POST /users/42/avatar
Content-Type: multipart/form-data
Authorization: Bearer eyJhbGci...

[binary file data]

A szerver visszaküldi:

HTTP/1.1 200 OK
Content-Type: application/json

{
  "avatar_url": "https://cdn.example.com/avatars/42.jpg",
  "updated_at": "2026-04-30T10:15:00Z"
}

Ha a user nem be van lépve:

HTTP/1.1 401 Unauthorized
{ "error": "Authentication required" }

Ha be van lépve, de nincs joga módosítani más profilját:

HTTP/1.1 403 Forbidden
{ "error": "You can only update your own profile" }

---

Példa 3: Hibás API tervezés – amit kerülj el

// ROSSZ – ige az URL-ben, nem erőforrás
POST /createUser
GET  /getUserById?id=42
GET  /deletePost?id=15  // GET ne töröljön!

// JÓ – erőforrás-orientált
POST /users
GET  /users/42
DELETE /posts/15

// ROSSZ – minden 200-at ad vissza, hibás esetben is
HTTP/1.1 200 OK
{ "success": false, "error": "User not found" }

// JÓ – a státuszkód tükrözi a valóságot
HTTP/1.1 404 Not Found
{ "error": "User not found" }

Ez az utóbbi hiba különösen csúnya, mert a frontend nem tudja, hogy 200 OK esetén is lehet hiba – le kell ellenőriznie a body-t is. A fejlesztők utálják.

---

Példa 4: API hívás különböző nyelveken

Python (requests):

import requests

response = requests.get(
    "https://api.example.com/users/42",
    headers={"Authorization": "Bearer my-token"}
)

if response.status_code == 200:
    user = response.json()
    print(user["name"])
elif response.status_code == 404:
    print("Felhasználó nem található")

JavaScript (fetch):

const response = await fetch("https://api.example.com/users/42", {
    headers: { "Authorization": "Bearer my-token" }
});

if (response.ok) {
    const user = await response.json();
    console.log(user.name);
} else if (response.status === 404) {
    console.log("Felhasználó nem található");
}

PHP (Laravel HTTP Client):

$response = Http::withToken('my-token')
    ->get('https://api.example.com/users/42');

if ($response->successful()) {
    $user = $response->json();
    echo $user['name'];
} elseif ($response->status() === 404) {
    echo 'Felhasználó nem található';
}

---

Tesztfeladatok

1. feladat – HTTP metódus választás

Melyik HTTP metódust használnád az alábbi műveletekhez? Indokold meg a döntésedet.

a) Egy cikk elolvasása (lekérése) az ID alapján
b) Új komment hozzáadása egy cikkhez
c) Saját felhasználóneved megváltoztatása (csak azt a mezőt)
d) Egy régi bejegyzés teljes tartalmának és metaadatainak felülírása
e) Egy értesítés törlése

---

2. feladat – Státuszkód párosítás

Kösd össze a szituációt a megfelelő HTTP státuszkóddal!

---

3. feladat – URL tervezés

Tervezd meg egy könyvtári API URL struktúráját az alábbi műveletekhez. Feltétel: RESTful elvek szerint, nem tartalmazhat igéket az URL-ben.

Műveletek:

• Összes könyv listázása
• Egy konkrét könyv részletei (ID alapján)
• Új könyv hozzáadása
• Könyv adatainak módosítása (részleges)
• Könyv törlése
• Egy adott könyv összes kölcsönzési rekordjának listázása

---

4. feladat – Kérés értelmezése

Olvasd el az alábbi HTTP kérést, és válaszolj a kérdésekre!

PATCH /api/v2/products/88/price HTTP/1.1
Host: shop.example.com
Authorization: Bearer eyJhbGci...abc
Content-Type: application/json
Accept: application/json

{
  "price": 4990,
  "currency": "HUF"
}

Kérdések:

• a) Mit csinál ez a kérés?
• b) Miért PATCH és nem PUT?
• c) Mi a szerepe az Authorization headernek?
• d) Mit vársz visszakapni, ha sikeres volt? (státuszkód + body felépítése)
• e) Mit vársz vissza, ha a 88-as termék nem létezik?

---

5. feladat – Hibás API tervezés azonosítása

Az alábbi API tervből azonosítsd a hibákat és indokold, mi a helyes megoldás!

GET  /getAllUsers
GET  /getUserDetails?id=5
POST /createNewProduct
GET  /deleteOrder?orderId=12
PUT  /updateUserEmail?userId=3&newEmail=test@example.com

---

6. feladat – Státuszkód kategóriák

Sorold be az alábbi státuszkódokat a megfelelő kategóriába (siker / klienshiba / szerverhiba / átirányítás), és egy mondatban írd le, mit jelent!

200, 201, 204, 301, 400, 401, 403, 404, 422, 429, 500, 503

---

7. feladat – JSON validáció

Az alábbi JSON-okban van hiba. Találd meg és javítsd ki!

a)

{
  name: "Kovács Péter",
  "email": "peter@example.com"
}

b)

{
  "id": 1,
  "active": True,
  "score": 8.5,
}

c)

{
  "tags": ["python", "backend",],
  "level": null
}

---

8. feladat – 401 vs 403

Magyarázd el saját szavaiddal a különbséget a 401 és 403 státuszkód között! Adj egy-egy valós példát, mikor melyiket adja vissza egy szerver.

---

9. feladat – GET kérés mellékhatása

Egy fejlesztő az alábbi URL-t tervezi:

GET /orders/55/confirm

Szándéka: az URL meghívásával a 55-ös rendelés megerősítéssel jár (státusza "confirmed"-re változik).

Mi a probléma ezzel a tervvel? Mi lenne a helyes megoldás és miért?

---

10. feladat – API hibakezelés értékelése

Kaptál egy API-t, amely az összes kérésre 200-at ad vissza, de a body-ban jelzi, hogy hiba volt:

{
  "success": false,
  "error_code": "NOT_FOUND",
  "message": "The requested resource does not exist."
}

• a) Mi a probléma ezzel a megközelítéssel?
• b) Hogyan érintené ez a frontend fejlesztők munkáját?
• c) Mi a helyes REST konvenciók szerinti megoldás?