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é.

Vztah k ostatním pojmům

HTTP je společná vrstva, ne hotové API.

Příbuzné pojmy doplňují jeho zabezpečení, popis zprávy nebo aplikační styl.

HTTPS a TLS: TLS chrání přenos HTTP zprávy mezi klientem a koncem spojení. Neurčuje oprávnění uživatele.
REST API: REST používá HTTP semantiku jako architektonický styl. Ne každé HTTP API je RESTful.
HTTP hlavička: Hlavičky nesou řídicí data, metadata reprezentace, cache pravidla či autentizační informace.
Reverse proxy: Proxy doručuje HTTP provoz k backendu a může řešit TLS, routing či limity před aplikací.

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.

Jak pracuji s API a integracemi Nezávazně probrat projekt