Slovník pojmů

Klient a server

Klient žádá o službu; server ji poskytuje a rozhoduje o jejím výsledku. Tyto role neznamenají jeden prohlížeč proti jednomu fyzickému počítači.

Stručná definice

Role v komunikaci, ne název jedné technologie.

Klientem je software, který službu využívá: nejčastěji prohlížeč, ale také mobilní aplikace, integrační služba, příkazový nástroj nebo automatický import. Server poskytuje funkci nebo data, přijímá požadavky a aplikuje pravidla svého kontraktu.

Za jednou veřejnou adresou může být DNS, reverse proxy, více aplikačních instancí, cache a databázové služby. Naopak jedna serverová aplikace může být klientem jiného API. Označení závisí na konkrétním směru komunikace.

Jaký problém řeší

Rozděluje využití služby od jejího poskytování

Klient-server model umožňuje, aby stejný backend využilo více různých zařízení a automatizovaných systémů.

prohlížeč a mobilní aplikace používají stejné API
interní administrace, e-shop a partner čtou či mění data přes definovaný kontrakt
reverse proxy skryje vnitřní topologii a předá požadavek správné službě
server centrálně ověřuje data, identitu a oprávnění, místo aby důvěřoval klientovi
monitoring pracuje se stavem odpovědi, latencí a dostupností komunikace

Praktický příklad

Tři klienti jednoho objednávkového API

Webový frontend, mobilní aplikace a interní skladový systém mohou používat stejné API pro načtení objednávky. Každý klient má jiný způsob zobrazení či automatizace, ale server pro všechny ověřuje stejný tenant, identitu a oprávnění.

V odpovědi server vrací HTTP stavový kód, hlavičky a případně JSON. Přijetí odpovědi 202 například může znamenat, že server úlohu přijal ke zpracování, nikoli že skladová synchronizace už skutečně doběhla.

GET /api/orders/ORD-42 HTTP/1.1
Host: api.example.cz
Accept: application/json

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

{"id":"ORD-42","status":"paid"}

Jak funguje

Od URL ke službě a zpět

Zjednodušený tok jedné HTTP komunikace ukazuje, kde vznikají hranice odpovědnosti.

Klient zná URL Prohlížeč nebo jiný program určí zdroj, metodu, hlavičky a případné tělo požadavku.
DNS a HTTPS Doménové jméno se přeloží na síťový cíl a TLS ověří server a chrání přenos.
Veřejná vstupní vrstva Webový server nebo reverse proxy může směrovat požadavek, ukončit TLS a uplatnit technické limity.
Aplikační server Backend provede autentizaci, autorizaci, validaci a business logiku nad daty.
Response pro klienta Server vrátí stav, metadata a obsah. Klient rozhodne, jak výsledek zobrazí nebo automaticky zpracuje.

Důležité pojmy

Klient, server a prostředník mají rozdílné role.

Rozlišení pomáhá správně navrhnout důvěru, chyby i provozní hranice.

Request a response

Požadavek iniciuje klient; odpověď popisuje výsledek. Jejich přesný význam stanoví HTTP a kontrakt dané služby.

User agent

Program jednající za uživatele, často prohlížeč. Uživatel a klient ale nejsou stejné pojmy.

Server jako software i infrastruktura

Může jít o aplikaci, která poskytuje službu, nebo zkráceně o infrastrukturu, kde běží. Kontext rozhoduje o významu.

Proxy

Prostředník může přeposílat provoz, cachovat nebo směrovat requesty. Serverová aplikace musí důvěřovat forwarding hlavičkám jen od známé proxy.

Bezstavové HTTP

HTTP mezi requesty samo nedrží uživatele. Aplikace může použít cookie, session nebo token, ale každý request musí být bezpečně vyhodnocen.

Vztah k podobným pojmům

Klient není frontend a server není nutně backend.

Role komunikace a rozdělení aplikace se často překrývají, ale nejsou totožné.

Klient a uživatel: Jeden uživatel může použít více klientů a automatizovaný klient nemusí reprezentovat člověka.
Server a backend: Backend je aplikační logika; server může být webový server, databáze, proxy nebo fyzická infrastruktura.
Klient a frontend: Frontend je uživatelské rozhraní a často klient API. Worker nebo integrační skript je klient bez grafického rozhraní.
Request a webhook: Webhook je serverem aktivně odeslané oznámení na callback URL; odesílatel tím pro daný tok vystupuje jako klient.

Výhody a omezení

Síťová komunikace přidává sdílení i nejistotu.

Přínosy

stejná služba může obsloužit web, mobilní klient i integraci
jasný kontrakt odděluje klientské rozhraní od implementace služby
infrastruktura může škálovat a chránit vstupní hranici nezávisle na klientovi
standardní HTTP nástroje usnadňují cache, monitoring a troubleshooting

Časté chyby

důvěřovat hodnotě role, ceny nebo tenanta poslané klientem
předpokládat, že odpověď znamená dokončení všech asynchronních následků
považovat server za jeden fyzický stroj
opakovat mutaci po timeoutu bez idempotence a kontraktu služby

Kdy dává smysl

Je to základní model webu i systémových integrací.

Model klienta a serveru je užitečný všude, kde jedna strana používá funkce druhé – od načtení stránky po předání objednávky dopravci. Pomáhá rozlišit, odkud přichází nedůvěryhodný vstup a kde musí vzniknout autoritativní rozhodnutí.

Pro některé scénáře existují i jiné komunikační modely, například fronty zpráv nebo peer-to-peer. I tehdy ale konkrétní komponenta často zároveň vystupuje jako klient jiné služby a server pro další část systému.

Na co myslet

Síť není bezchybná a klient není důvěryhodný.

Dobrý návrh počítá s výpadkem, zpožděním i změněným požadavkem.

validovat a autorizovat data na serveru, ne pouze v prohlížeči
používat HTTPS a správně ověřovat důvěryhodné proxy
popsat statusy, chyby, timeouty a retry v API kontraktu
nevyvozovat dokončení business procesu jen z přijatého requestu
logovat korelační informace bez citlivých tokenů a osobních údajů

Časté otázky

Co se o klientu a serveru často plete

Je prohlížeč vždy klient?

V klasické webové komunikaci ano. Klientem ale může být také mobilní aplikace, cron, Postman nebo jiná serverová služba.

Je databáze server?

V databázovém protokolu poskytuje databázová služba serverovou roli. V popisu webu je ale obvykle závislostí aplikačního serveru, ne HTTP serverem pro uživatele.

Je reverse proxy backend?

Je to infrastrukturní prostředník. Může být součástí provozního celku, ale běžně neobsahuje doménovou logiku aplikace.

Může server posílat data bez requestu?

Klasické HTTP je request–response. SSE začíná requestem klienta a WebSocket přechází na jiný obousměrnější provozní model.

Jak pracuji s API v praxi

Komunikaci mezi systémy navrhuji jako jasný kontrakt.

U e-commerce a integrací řeším klienty, API, idempotenci, chyby a provozní chování tak, aby byla komunikace dohledatelná i při výpadcích.

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