\section{HTTP és HTTPS}

\begin{frame}{Mi a HTTP?}
\footnotesize
Amikor a böngésződ betölt egy weboldalt, vagy amikor egy mobilalkalmazás adatot kér egy szervertől, a háttérben szinte mindig a \textbf{HTTP} (HyperText Transfer Protocol) protokoll zajlik. Ez egy egyszerű, szövegalapú szabályrendszer arra, hogyan kérjen adatot egy kliens (pl. böngésző) egy szervertől, és hogyan válaszoljon arra a szerver.

\begin{itemize}
\item Kliens-szerver kommunikáció alapja a weben
\item \textbf{Állapotmentes (stateless)} protokoll: a szerver alapból nem emlékszik az előző kérésekre -- minden kérés önmagában, a többitől függetlenül értelmezhető
\item \textbf{Request-Response} modell: a kliens kér, a szerver válaszol
\item Alapértelmezett port: 80 (HTTP), 443 (HTTPS)
\end{itemize}
\end{frame}

\begin{frame}{HTTP verziók}
\footnotesize
A HTTP protokoll az évek során több jelentős verzióváltáson esett át, mindig azzal a céllal, hogy gyorsabbá és hatékonyabbá tegye a weben zajló kommunikációt. Ma leggyakrabban HTTP/1.1-gyel és HTTP/2-vel találkozunk, de egyre több nagy szolgáltatás áll át a legújabb HTTP/3-ra is.

\begin{block}{}
\begin{itemize}
\item \textbf{HTTP/1.1} (1997) -- perzisztens kapcsolat, azaz nem kell minden kéréshez új TCP-kapcsolatot nyitni
\item \textbf{HTTP/2} (2015) -- multiplexing (több kérés egyszerre, egy kapcsolaton), bináris protokoll
\item \textbf{HTTP/3} (2022) -- a QUIC protokollra épül, UDP alapú, még gyorsabb kapcsolatfelépítés
\end{itemize}
\end{block}
\end{frame}

\begin{frame}{HTTP vs HTTPS}
\footnotesize
A sima HTTP-n keresztül küldött adatokat bárki, aki hozzáfér a hálózati forgalomhoz (pl. egy nyílt wifin), el tudja olvasni, sőt módosítani is. A \textbf{HTTPS} ezt a problémát oldja meg azzal, hogy a HTTP forgalmat egy titkosítási réteg (SSL/TLS) fölé csomagolja.

\begin{columns}
\begin{column}{0.48\textwidth}
\begin{block}{HTTP}
\begin{itemize}
\item Titkosítatlan kommunikáció
\item Lehallgatható, módosítható (Man-in-the-Middle támadás)
\item Port 80
\end{itemize}
\end{block}
\end{column}
\begin{column}{0.48\textwidth}
\begin{block}{HTTPS = HTTP + SSL/TLS}
\begin{itemize}
\item Titkosított kommunikáció
\item SSL/TLS tanúsítvány szükséges hozzá
\item Port 443
\end{itemize}
\end{block}
\end{column}
\end{columns}
\end{frame}

\begin{frame}{Miért kötelező ma a HTTPS?}
\footnotesize
Régebben csak a bejelentkezős, kényes adatokat kezelő oldalak használtak HTTPS-t, ma viszont gyakorlatilag minden weboldalnak ezt kellene tennie -- több okból is.

\begin{alertblock}{Fontos}
Modern webalkalmazásoknál a HTTPS gyakorlatilag kötelező: a böngészők figyelmeztetést adnak a sima HTTP oldalakra, a keresőmotorok (SEO) hátrébb sorolják őket, és sok modern böngésző-funkció (pl. helymeghatározás, kamera) is csak HTTPS mellett engedélyezett.
\end{alertblock}

\begin{itemize}
\item \textbf{Bizalom:} a felhasználó látja a lakat ikont, tudja, hogy az adatai védve utaznak
\item \textbf{Integritás:} útközben senki nem tudja módosítani a forgalmat (pl. reklámot beszúrni)
\item \textbf{Hitelesség:} a tanúsítvány igazolja, hogy tényleg azzal a szerverrel beszélünk, akivel hisszük
\end{itemize}
\end{frame}

\begin{frame}{HTTP metódusok}
\footnotesize
Minden HTTP kérésnek van egy \textbf{metódusa}, ami megmondja, milyen műveletet szeretnénk végrehajtani az adott erőforráson. A REST API-k tervezésénél ez a metódusválasztás lesz az egyik legfontosabb döntésünk.

\begin{tabular}{|l|p{7cm}|}
\hline
\textbf{Metódus} & \textbf{Jelentés} \\
\hline
GET & Erőforrás lekérése (csak olvasás, idempotens) \\
POST & Új erőforrás létrehozása (nem idempotens) \\
PUT & Erőforrás teljes frissítése (idempotens) \\
PATCH & Erőforrás részleges frissítése (nem idempotens) \\
DELETE & Erőforrás törlése (idempotens) \\
HEAD & Mint GET, de csak fejlécek, body nélkül \\
OPTIONS & Támogatott metódusok lekérése (CORS) \\
\hline
\end{tabular}
\end{frame}

\begin{frame}{Idempotencia -- miért számít?}
\footnotesize
Egy művelet \textbf{idempotens}, ha többszöri végrehajtása ugyanazt az eredményt adja, mint az egyszeri. Ennek nagy jelentősége van a gyakorlatban: ha egy kérés elakad a hálózaton és a kliens újraküldi, idempotens metódusnál (GET, PUT, DELETE) nem történik semmi baj -- a végállapot ugyanaz marad.

\begin{block}{Példa}
Ha kétszer küldöd el ugyanazt a \texttt{DELETE /api/users/123} kérést, a felhasználó csak egyszer törlődik -- a második kérés egyszerűen nem talál már semmit, amit törölnie kellene.
\end{block}

\begin{alertblock}{POST nem idempotens}
Ha egy \texttt{POST}-tal új erőforrást hozunk létre, és véletlenül kétszer küldjük el (pl. dupla kattintás egy "Rendelés leadása" gombon), két különálló erőforrás (pl. két rendelés) jöhet létre!
\end{alertblock}
\end{frame}

\begin{frame}[fragile]{HTTP Request felépítése}
\footnotesize
Egy HTTP kérés mindig ugyanabból a három részből épül fel: egy sorból, ami leírja, mit kérünk, néhány fejlécből, és opcionálisan egy törzsből (body).

\begin{block}{Request struktúra}
\begin{verbatim}
GET /api/users/123 HTTP/1.1
Host: example.com
Accept: application/json
Authorization: Bearer token123
\end{verbatim}
\end{block}

\begin{itemize}
\item \textbf{Request Line:} metódus (GET), útvonal (\texttt{/api/users/123}), protokoll verzió
\item \textbf{Headers:} metaadatok kulcs-érték párok formájában (pl. milyen formátumot fogadunk el, kik vagyunk)
\item \textbf{Body:} opcionális adatok, jellemzően POST, PUT, PATCH kéréseknél (pl. egy új felhasználó adatai JSON-ban)
\end{itemize}
\end{frame}

\begin{frame}[fragile]{HTTP Response felépítése}
\footnotesize
A szerver válasza (response) hasonló szerkezetű, csak itt a kérés helyett egy \textbf{státuszkód} mondja meg, hogy sikerült-e a kérés.

\begin{block}{Response struktúra}
\begin{verbatim}
HTTP/1.1 200 OK
Content-Type: application/json

{"id": 123, "name": "Alice"}
\end{verbatim}
\end{block}

\begin{itemize}
\item \textbf{Status Line:} protokoll, státuszkód (200), státusz szöveg (OK)
\item \textbf{Headers:} metaadatok (pl. milyen formátumú a válasz törzse)
\item \textbf{Body:} a válasz tényleges tartalma (HTML, JSON, XML, stb.)
\end{itemize}
\end{frame}

\begin{frame}{HTTP státuszkódok}
\footnotesize
A státuszkód egy háromjegyű szám, aminek az \emph{első számjegye} határozza meg a kategóriáját. Nem kell mind a száznál is több kódot fejből tudni -- elég, ha felismered, melyik kategóriába tartozik egy adott kód.

\begin{itemize}
\item \textbf{1xx -- Informational:} ritkán találkozunk vele, ideiglenes válasz (pl. 101 Switching Protocols)
\item \textbf{2xx -- Success:} a kérés sikeres volt (200 OK, 201 Created, 204 No Content)
\item \textbf{3xx -- Redirection:} a kliensnek egy másik URL-re kell mennie (301 Moved Permanently, 302 Found, 304 Not Modified)
\item \textbf{4xx -- Client Error:} a kliens hibázott (400 Bad Request, 401 Unauthorized, 403 Forbidden, 404 Not Found, 429 Too Many Requests)
\item \textbf{5xx -- Server Error:} a szerver oldalán történt hiba, a kliens kérése önmagában helyes volt (500 Internal Server Error, 502 Bad Gateway, 503 Service Unavailable)
\end{itemize}
\end{frame}

\begin{frame}{REST API-ban gyakori státuszkódok}
\footnotesize
Egy jól megtervezett REST API mindig következetesen használja a státuszkódokat -- ez az egyik legfontosabb szokás, amit már most érdemes elsajátítani, hiszen a következő heteken folyamatosan ezekkel fogunk dolgozni.

\begin{tabular}{|l|l|l|}
\hline
\textbf{Metódus} & \textbf{Sikeres} & \textbf{Hiba} \\
\hline
GET & 200 OK & 404 Not Found \\
POST & 201 Created & 400, 409 Conflict \\
PUT & 200 OK / 204 No Content & 400, 404 Not Found \\
PATCH & 200 OK & 400, 404 Not Found \\
DELETE & 204 No Content & 404 Not Found \\
\hline
\end{tabular}

\begin{block}{Két gyakori, metódusfüggetlen eset}
Autentikáció: 401 Unauthorized (nincs bejelentkezve), 403 Forbidden (be van jelentkezve, de nincs jogosultsága) \\
Szerver hiba: 500 Internal Server Error, 503 Service Unavailable
\end{block}
\end{frame}

\begin{frame}{HTTPS -- SSL/TLS Handshake}
\footnotesize
Mielőtt egy HTTPS kapcsolaton bármilyen adat átmenne, a kliens és a szerver egy rövid "kézfogáson" (handshake) esik át, aminek célja, hogy közösen kialakítsanak egy titkos kulcsot, amit csak ők ketten ismernek.

\begin{enumerate}
\item \textbf{Client Hello} -- a kliens elküldi, milyen titkosítási módokat támogat
\item \textbf{Server Hello} -- a szerver kiválasztja a közösen támogatott titkosítást, és elküldi a tanúsítványát
\item \textbf{Certificate Verify} -- a kliens ellenőrzi a tanúsítványt egy megbízható hitelesítésszolgáltatónál (CA)
\item \textbf{Key Exchange} -- létrejön egy közös, szimmetrikus titkosító kulcs
\item \textbf{Finished} -- innentől minden adat ezzel a kulccsal titkosítva utazik
\end{enumerate}

\begin{block}{SSL/TLS verziók}
A TLS 1.2 még sok helyen használatban van, de a TLS 1.3 az ajánlott: gyorsabb kapcsolatfelépítés és erősebb, biztonságosabb titkosítási módok.
\end{block}
\end{frame}

\begin{frame}{Összefoglalás -- HTTP/HTTPS}
\footnotesize
\begin{block}{HTTP/HTTPS alapok}
\begin{itemize}
\item HTTP: Request-Response modell, állapotmentes (stateless) protokoll
\item HTTPS: titkosított HTTP, SSL/TLS handshake-kel
\item HTTP metódusok: GET, POST, PUT, PATCH, DELETE -- mindegyiknek megvan a maga szerepe
\item Idempotencia: GET, PUT, DELETE biztonságosan újraküldhető
\item Státuszkódok: az első számjegy adja meg a kategóriát (1xx--5xx)
\item REST API-ban leggyakrabban használt kódok: 200, 201, 204, 400, 401, 403, 404, 500
\end{itemize}
\end{block}
\end{frame}