HTTP-metódusok és a kérés szándéka

Célok

A lecke végére meg tudod mondani, mire való a GET, a POST, a PUT, a PATCH és a DELETE, el tudod különíteni a biztonságos és az idempotens metódusokat, és érted, miért veszélyes a GET-tel módosítani az adatot.

Miért nem elég a cím?

Az URL azt mondja meg, melyik erőforrásról van szó. De ugyanarról a kurzusról kérdezhetünk („milyen adatai vannak?”), módosíthatjuk, törölhetjük, vagy jelentkezhetünk rá. A cím ezt nem tudja kifejezni. A HTTP-metódus a kérés szándékát jelzi: ugyanaz a cím más-más művelet célpontja lehet. A szerver, a böngésző és a közbülső gépek (például gyorsítótárak) is ebből döntik el, mit szabad velük tenni.

Ugyanaz a cím, eltérő művelet

$ curl -i http://localhost:8080/api/kurzusok -H 'Accept: application/json'
HTTP/1.1 200 OK
Content-Type: application/json; charset=utf-8
...
[{"id":"webprog","cim":"Webprogramozás 1.","ferohely":40,"jelentkezett":31},{"id":"adatbazisok","cim":"Adatbázisok","ferohely":60,"jelentkezett":60}]

$ curl -i -X POST http://localhost:8080/jelentkezesek \
    -H 'Content-Type: application/json' -d '{"kurzus":"webprog"}'
HTTP/1.1 201 Created
Content-Type: application/json; charset=utf-8
Location: /jelentkezesek/1
...
{"id":1,"kurzus":"webprog"}

Az első kérés egy erőforrást ismer meg, a második adatot küld feldolgozásra: a szerver ennek alapján új jelentkezést hozhat létre. A metódus önmagában nem hajtja végre a műveletet: a szervernek ellenőriznie kell, jogosult-e a kérő, van-e hely, értelmes-e az adat.

flowchart TB
    C[Kérés egy URL-hez] --> M{Metódus}
    M -->|GET| O[Erőforrás lekérése]
    M -->|POST| F[Adat feldolgozása, művelet indítása]
    M -->|PUT, PATCH| V[Módosítás]
    M -->|DELETE| D[Törlés]

GET: lekérdezés

A GET erőforrást kér. Rendeltetése szerint nem okoz üzleti állapotváltozást: egy kurzusoldal megnyitása nem vehet fel automatikusan kurzust. A szerver naplózhatja a kérést, de a felhasználó által kért alkalmazási állapot nem változhat tőle.

A GET-címeket gyakran megosztják, könyvjelzőzik, gyorsítótárazzák, és automatikus programok (keresőrobot, előnézet-készítő) is megnyithatják. Ezért veszélyes, ha például egy /jelentkezes-torles?id=42 cím GET-kérése törlést indít: egy robot egyszerűen kitörölhetné a jelentkezéseket.

POST: feldolgozásra küldött adat

A POST adatot küld a szervernek, amely ez alapján új erőforrást hozhat létre vagy műveletet indíthat. A fenti példában a törzs a kurzus azonosítóját hordozza, a szerver pedig 201 Created választ ad, és a Location fejlécben megadja az új erőforrás címét.

További metódusok

Metódus	Alapvető jelentés	Példa
HEAD	Mint a GET, de a válaszban nincs törzs	Erőforrás jellemzőinek (például méretének) ellenőrzése
PUT	Az erőforrás teljes tartalmának cseréje	Profil teljes frissítése
PATCH	Az erőforrás részleges módosítása	Egyetlen mező módosítása
DELETE	Erőforrás törlése	Jelentkezés visszavonása
OPTIONS	Az erőforrás kommunikációs lehetőségeinek lekérdezése	Böngészős biztonsági ellenőrzés (8. fejezet)

Hogy pontosan mit jelent például a PUT egy adott szolgáltatásban, az az API szabályaitól is függ (5. fejezet). A HEAD kimenete:

$ curl -I http://localhost:8080/profil
HTTP/1.1 200 OK
Content-Type: application/json; charset=utf-8
Content-Length: 33
...

A válaszban megvannak a fejlécek, de a törzs nem érkezik meg.

Biztonságos és idempotens

Két fogalom segít eldönteni, mennyire „szabad” egy kérést ismételni vagy előre elküldeni.

• Biztonságos (safe) metódus: rendeltetése szerint nem változtatja meg a szerver állapotát, csak olvas. Az RFC 9110 szerint ilyen a GET, a HEAD, az OPTIONS és a TRACE. A „biztonságos” itt nem azt jelenti, hogy titkosított.
• Idempotens (idempotent) metódus: egymás utáni többszöri végrehajtása ugyanazt az eredményt adja, mint az egyszeri. Az RFC 9110 szerint idempotens a PUT, a DELETE és minden biztonságos metódus. A POST nem az.

Kipróbálva, a helyi szerveren:

$ curl -X POST .../jelentkezesek -d '{"kurzus":"webprog"}'     # kétszer
{"id":1,"kurzus":"webprog"}
{"id":2,"kurzus":"webprog"}

A POST ismétlése két külön jelentkezést hozott létre.

$ curl -X PUT .../profil -d '{"nev":"Minta Anna","evfolyam":2}' # kétszer
{"nev":"Minta Anna","evfolyam":2}
{"nev":"Minta Anna","evfolyam":2}

A PUT kétszeri végrehajtása után a profil ugyanaz.

$ curl -i -X DELETE .../jelentkezesek/1                        # kétszer
HTTP/1.1 204 No Content
HTTP/1.1 404 Not Found

A DELETE második hívása más státuszkódot ad (az erőforrás már nincs meg), de a szerver állapota ugyanaz: a jelentkezés nincs benne. Az idempotencia tehát az állapotra vonatkozik, nem arra, hogy a válasz azonos.

Végigvezetett példa: miért POST a jelentkezés?

A Kurzuspontban a kurzus megnyitása GET: bárki megnyithatja, megoszthatja, a gyorsítótár megőrizheti. A jelentkezés POST, mert állapotot változtat (egy hellyel kevesebb), nem ismételhető következmény nélkül, és nem is szabad, hogy egy robot a linket megnyitva jelentkezést indítson. A lemondás DELETE, mert az eredmény ismétlés után is „nincs jelentkezés”.

Az ismételt POST-ot a felületnek és a szervernek is kezelnie kell: a felület letiltja a gombot a küldés idejére, a szerver pedig felismeri, ha ugyanaz a hallgató ugyanarra a kurzusra már jelentkezett.

Gyakori tévhitek

Állítás	Pontosítás
„A GET nem változtathat semmit a szerveren.”	Naplózás történhet; az alkalmazás üzleti állapotát viszont nem szabad vele módosítani.
„A POST miatt az adat titkos.”	A metódus nem helyettesíti a HTTPS-t és a jogosultság-ellenőrzést.
„Az URL önmagában megmondja a műveletet.”	A metódus is része a kérés jelentésének.
„Az idempotens mindig ugyanazt a választ adja.”	Az állapot azonos, a válaszkód különbözhet (lásd a DELETE-et).
„A biztonságos metódus titkosított.”	A „biztonságos” az állapotváltoztatás hiányát jelenti.

Röviden

• A metódus a kérés szándékát jelzi: GET lekér, POST feldolgoztat, PUT cserél, PATCH módosít, DELETE töröl.
• A biztonságos metódus nem módosít állapotot; az idempotens metódus ismétlése ugyanazt az állapotot adja.
• A POST ismétlése duplikált műveletet okozhat, ezért külön védekezés kell.
• Állapotot módosító műveletet soha nem szabad GET-tel megvalósítani.

Ellenőrző kérdések

1. Miért nem lehet a lemondás egyszerű GET-hivatkozás?
2. Mi a különbség a PUT és a PATCH között?
3. Miért nem idempotens a POST? Mutass példát!
4. Mit jelent az, hogy a DELETE második hívása más státuszkódot ad, mégis idempotens?

Tanulási források

• HTTP request methods (MDN) — a metódusok és a biztonságos–idempotens–gyorsítótárazható táblázat, angolul.
• HTTP Semantics, RFC 9110 — a metódusok hivatalos definíciója (9. szakasz).