Jan Mikoláš
Slovník pojmů
HTTP
HTTP dává klientovi a serveru společný jazyk pro požadavek, odpověď a jejich význam. Neříká ale, jak má vypadat doménový model, databáze ani oprávnění uživatele.
Stručná definice
Jednotné rozhraní mezi klientem, serverem a prostředníky.
HTTP je rodina bezstavových aplikačních protokolů typu request–response. Klient pošle požadavek na konkrétní zdroj, například stránku produktu nebo API endpoint objednávky. Server jej vyhodnotí a vrátí odpověď se stavovým kódem, hlavičkami a podle potřeby tělem, například HTML nebo JSONem.
Základní význam metod, stavových kódů a hlaviček je společný pro HTTP/1.1, HTTP/2 i HTTP/3. Verze se liší způsobem přenosu a souběhem zpráv, ne tím, že by POST nebo 404 získaly jiný aplikační význam. HTTP může běžet přes různé transporty; na webu se zpravidla používá přes TLS jako HTTPS.
K čemu se používá
Od dokumentu v prohlížeči po integrační API
HTTP nezávisí na tom, zda klientem je člověk, aplikace nebo automatický worker.
- načtení webové stránky, CSS, JavaScriptu, obrázku nebo souboru
- volání REST API z frontendu, mobilní aplikace nebo partnerské integrace
- přijetí webhooku od marketplace, dopravce nebo platební brány
- komunikace mezi reverse proxy, gateway a interní HTTP službou
- zdravotní kontroly, dokumentace API a strojově čitelné chybové odpovědi
Praktický příklad
Načtení stavu objednávky přes API
Administrace potřebuje zobrazit objednávku. Pošle GET na zdroj s identifikátorem objednávky a přiloží autentizační údaj v hlavičce. API ověří, zda uživatel smí objednávku v daném tenantovi číst, a vrátí JSON reprezentaci nebo odpovídající chybu. Status 200 sám nestačí jako důkaz oprávnění; to provedl backend.
Příklad je záměrně HTTP/1.1 zápis pro čitelnost. V HTTP/2 nebo HTTP/3 mohou zprávy cestovat jinak, ale význam metody, hlaviček a odpovědi zůstává stejný.
GET /api/orders/ORD-2026-42 HTTP/1.1
Host: api.example.cz
Accept: application/json
Authorization: Bearer <token>
HTTP/1.1 200 OK
Content-Type: application/json
Cache-Control: no-store
{"id":"ORD-2026-42","status":"paid"}Jak funguje
Od záměru klienta k interpretované odpovědi
HTTP přenáší zprávu; správný význam vzniká až kombinací metody, URI, hlaviček, těla a dokumentovaného kontraktu.
- Klient sestaví request Zvolí metodu, cílovou URI, hlavičky a případně tělo. Metoda popisuje záměr, například čtení nebo vytvoření zdroje.
- Síť a prostředníci DNS, TLS, reverse proxy nebo cache mohou request doručit dále. Proxy nesmí domýšlet business význam operace jen podle cesty.
- Server vyhodnotí zdroj Aplikace provede autentizaci, autorizaci, validaci a vlastní logiku. HTTP samo tyto kontroly neposkytuje.
- Server vrátí response Stavový kód popíše výsledek, hlavičky nesou metadata a tělo vrací reprezentaci zdroje nebo detail chyby.
- Klient rozhodne o dalším kroku Podle kódu, hlaviček a dokumentovaného formátu zobrazí výsledek, přesměruje uživatele, obnoví cache nebo řeší chybu.
Hlavní části a pojmy
Metoda, zdroj a zpráva mají oddělené role.
Znalost těchto hranic brání tomu, aby API odpovídalo neurčitě nebo aby infrastruktura nesla aplikační pravidla.
Zdroj a reprezentace
URI identifikuje cíl komunikace. Odpověď může vrátit jeho HTML, JSON nebo jinou reprezentaci; samotná URI nemusí prozrazovat interní strukturu tabulek či tříd.
Metody
GET čte reprezentaci, POST často vytváří nebo spouští akci, PUT nahrazuje cílový stav, PATCH jej mění částečně a DELETE žádá odstranění. Přesná business pravidla musí API určit samo.
Bezstavovost
Každý request má být srozumitelný samostatně. Server může držet relaci nebo data v databázi, ale význam nového requestu nemá záviset na skrytém pořadí předchozích HTTP zpráv na spojení.
Bezpečnost a idempotence
Bezpečná metoda nemá měnit stav; idempotentní opakování má mít stejný zamýšlený účinek. Neznamená to, že GET nesmí selhat ani že opakovaný DELETE musí vracet totožnou odpověď.
Verze HTTP a cache
HTTP/2 a HTTP/3 mění přenosové vlastnosti, ne aplikační semantiku. Cache řídí konkrétní hlavičky a pravidla odpovědi; nelze předpokládat, že vše přes GET je automaticky bezpečně cacheovatelné.
Výhody a omezení
Obecné rozhraní umožňuje spolupráci, ale nevytváří doménový kontrakt.
Přínosy
- společná pravidla pro web, API, klienty a prostředníky
- srozumitelné oddělení požadavku, odpovědi, metadat a obsahu
- možnost používat standardní nástroje pro cache, proxy, monitoring a dokumentaci
- nezávislost významu HTTP na konkrétním programovacím jazyce nebo frameworku
Omezení a časté chyby
- považovat HTTP status za úplný popis businessového výsledku
- vkládat citlivá data do URL, která se mohou objevit v logu nebo historii
- použít GET pro akci měnící stav
- opakovat zápis po timeoutu bez idempotentního návrhu
- zaměnit zabezpečené HTTPS spojení za autentizaci a autorizaci API
Kdy dává smysl
Pro veřejné i interní rozhraní, které potřebuje jasný kontrakt.
HTTP je přirozené rozhraní pro web a API, protože klienti, prohlížeče, proxy i monitoring jeho model znají. V e-commerce lze stejnými principy doručit katalog uživateli, přijmout webhook objednávky nebo nabídnout partnerské API; konkrétní datový model a pravidla se ale liší podle případu.
Pro interní velmi frekventovanou komunikaci může být vhodný jiný protokol nebo fronta zpráv. Ani tam však HTTP není „příliš jednoduché“ samo o sobě: důležitá je potřeba odpovědi v reálném čase, verzování kontraktu, retry, bezpečnost a pozorovatelnost celého toku.
Na co myslet
Význam requestu musí být jasný klientovi i provozu.
Dobré HTTP rozhraní využívá standardní semantiku tam, kde pomáhá, a zbytek popíše konkrétním kontraktem.
- vybírat metodu podle zamýšleného účinku a zdokumentovat netriviální akce
- pro odpověď použít odpovídající status, typ obsahu a stabilní chybový formát
- neposílat tajemství ani osobní údaje do URL a nevyvěšovat interní chyby klientovi
- u zápisových operací navrhnout timeout a retry spolu s idempotencí
- měřit statusy, latenci, velikost odpovědi a chyby na proxy i v aplikaci
Časté otázky
HTTP bez častých záměn
Je HTTP totéž co API?
Ne. API je rozhraní mezi programy a může používat HTTP, ale také jiné protokoly nebo přímé volání knihovny. HTTP je komunikační protokol.
Je HTTP bezstavové, když aplikace používá přihlášení?
Ano v tom smyslu, že každý request musí nést informace potřebné k pochopení svého významu. Server může relaci uložit a request ji identifikovat cookie nebo tokenem.
Je POST vždy ne-idempotentní?
Ne automaticky. Metoda sama obecně negarantuje idempotenci, ale konkrétní API může navrhnout idempotency key a opakovaný POST se stejným účinkem.
Zajišťuje HTTP bezpečný přenos hesla?
Ne. Běžné HTTP samo data nešifruje. Pro přenos přes nedůvěryhodnou síť se používá HTTPS, tedy HTTP přes TLS.
Jak pracuji s API v praxi
HTTP kontrakt navrhuji spolu s integrací, bezpečností a retry.
U e-commerce a integračních služeb řeším význam endpointů, chyby, autentizaci, idempotenci i provozní chování mezi klientem a backendem.