Technologie na serveru, architektura, REST

BI-WI.21-18
  • Základní postupy, technologie a standardy na straně serveru. Architektura webové aplikace a související návrhové vzory. REST.

Základní postupy

  • Klient typicky webový prohlížeč iniciuje požadavky na server, který na základě požadavku získá externí data a vykoná business logiku, následně klientovi vrací odpovědi.
  • Klient se stará o prezentaci dat, server o business logiku.
  • Klient a server spolu komunikují pomocí HTTP.

Životní cyklus požadavku

  • Webový server / Reverzní proxy (např. Nginx, Apache)

    • požadavek přijme,
    • vyřeší SSL/TLS šifrování a předá ho aplikačnímu serveru.

  • Routing (Směrování):

    • Aplikace podle URL a HTTP metody zjistí, který kód (Controller/Handler) má požadavek zpracovat.

  • Middleware (Filtry):

    • Požadavek projde sadou mezikroků (ověření přihlášení, logování, parsování JSON těla).

  • Byznys logika:

    • Provede se samotný kód (výpočty, zápis do databáze).
    • Zpracování formulářů a jejich validace
    • Správa session a cookies
    • Perzistence dat a ORM (Object-Relational Mapping)
      • Práce s databázemi pomocí objektového přístupu, abstrahující SQL (pomocí např. Doctrine v Symfony, Eloquent v Laravelu, SQLAlchemy v Pythonu, Hibernate v Javě, TypeORM v Node.js).
    • Šablonovací systémy (Templating Engines)
      • Umožňují oddělit logiku od prezentace generováním HTML (nebo jiných formátů) z dat (např. Twig v PHP, Jinja2 v Pythonu, Thymeleaf v Javě).

  • Generování odpovědi:

    • Server sestaví HTTP odpověď (přeloží objekty na JSON nebo vygeneruje HTML šablonu) a pošle ji zpět.

Technologie serverů

  • Apache HTTP

    • Jeden z nejstarších a nejrozšířenějších web serverů.
    • Flexibilní díky modulům
    • Používá model “proces na požadavek” nebo “vlákno na požadavek”, což je při vysoké zátěži méně efektivní ve srovnání s událostmi řízenými architekturami.

  • Nginx

    • Vysoce výkonný web server a reverse-proxy.
    • Zvládá velké množství souběžných spojení s nízkou spotřebou paměti, díky událostmi řízené architektuře
    • Často využíváno jako reverse-proxy před aplikačními servery, nebo pro load balancing a jako SSL/TLS terminátor

Technologie perzistence dat

  • In-memory

    • Data v RAM
    • Extrémně rychlé, ale data jsou ztracena při restartu.
    • Vhodné pro cache a krátkodobé sessions.

  • Filesystem

    • Data ukládána v souborech.
    • Nelze konkurentně přistupovat.
    • Pomalý zápis a čtení.

  • Databáze

    • Specializovaný systém pro efektivní ukládání, správu a dotazování dat
    • Obvykle poskytují mechanismy pro konkurenční přístup, transakce a indexaci.

Standardy a protokoly

(Zkrácená verze z otázky 17 TWA - HTTP Stavové kódy a 17 TWA - Historie HTTP verzí)

Standardy HTTP protokolu

  • HTTP/0.9

    • Testovací jednořádkový protokol
    • Pouze GET metoda

  • HTTP/1.0

    • Podpora hlaviček
    • Odpověď, status kódy

  • HTTP/1.1

    • Povinná hlavička Host (kvůli VirtualHost, více domén na jedné IP)
    • Možnost poslat odpověď ve více částech (chunk)
    • Podpora trvalého spojení (Connection: Keep-Alive)
    • Pokročilejší cacheování

  • HTTP/2

    • Binární přenos
    • Multiplexovaný
    • Podpora server-push

  • HTTP/3

    • Funguje nad UDP (protokol QUIC)
    • Zdokonaluje paralelní zpracování
    • Umožňuje jednoduší přechod mezi sítěmi (QUIC)

HTTP Stavové kódy

  • 1xx (Informační): Požadavek byl přijat, proces pokračuje. (Např. 100 Continue)
  • 2xx (Úspěch): Požadavek byl úspěšně přijat, pochopen a akceptován.
  • 3xx (Přesměrování): K dokončení požadavku je třeba provést další akci.
  • 4xx (Chyba klienta): Požadavek obsahuje chybnou syntaxi nebo nemůže být splněn.
  • 5xx (Chyba serveru): Server selhal při plnění zjevně platného požadavku.

Architektura webové aplikace

  • Architektura popisuje návrh z pohledu celé aplikace
  • Následující architektury nejsou úplným dělením
    • Většina se doplňuje
    • Můžu mít např. MVC a zároveň 2-vstvou thin-client / smart-server

Dvouvrstvá

  • Thin-client / Smart-server

    • Většina logiky aplikace je soustředěna na serveru
    • Klient pouze prezentuje data

  • Thick-client / Dumb-server

    • Modernější přístup často u SPA (Single Page Application).
    • Velká část aplikační logiky je u klienta a server funguje primárně jako API poskytující data a základní služby.

Vícevrstvá architektura

(Více viz otázka 12 SWI - Třívrstvá architektura)

  • Separace odpovědnosti rozdělení aplikace do logických vrstev.

  • Každá vrstva má specifickou roli a komunikuje se sousedními vrstvami

  • Cílem je abstrakce a snížení závislostí mezi částmi systému

  • Příklad typické třívrstvé architektury:

    • Prezentační vrstva - zodpovědná za UI a interakci s uživatelem. Zobrazuje data a sbírá vstupy od uživatele.
    • Aplikační/Logická vrstva - business logika, zpracovává požadavky od prezentační vrstvy, sbírá data z datové vrstvy provádí výpočty a poskytuje data prezentační vrstvě.
    • Datová vrstva - zodpovědná za persistenci dat, typicky pomocí databázového systému

  • Výhody:

    • Lepší organizace,
    • Snadnější údržba (změny v jedné vrstvě méně ovlivňují ostatní),
    • Možnost nezávislého vývoje a škálování jednotlivých vrstev.

  • Nevýhody:

    • Může přidat určitou režii v komunikaci mezi vrstvami a zvýšit počáteční komplexitu návrhu.

Monolith

  • Celá aplikace je vyvíjena a nasazována jako jedna nedělitelná jednotka.

  • Všechny komponenty (UI, business logika, přístup k datům) jsou úzce propojeny a běží v jednom “procesu”.

  • Výhody*:

    • Jednodušší počáteční vývoj a nasazení,
    • Přímočařejší testování (alespoň u menších aplikací).

  • Nevýhody*:

    • Škálování musí probíhat pro celý monolit, i když je přetížena jen jeho část, což vede k neefektivnímu využití zdrojů.
    • Změny v jedné části mohou snadno ovlivnit jiné části.

Microservices

  • Aplikace dekomponovaná na sadu malých, nezávisle nasaditelných služeb.

  • Jednotlivé služby jsou zodpovědné za specifickou business logiku (i např. s vlastní DB)

  • Komunikace mezi službami probíhá přes síť pomocí lehkých protokolů (HTTP/REST, gRPC)

  • Výhody*:

    • Vysoká škálovatelnost (jednotlivé služby lze škálovat nezávisle),
    • Technologická diverzita,
    • Lepší odolnost proti chybám (selhání jedné služby nemusí ovlivnit ostatní),
    • Snadnější údržba a rychlejší cykly nasazování menších částí.

  • Nevýhody*:

    • Zvýšená komplexnost správy distribuovaného systému, monitorování, ladění.
    • Nutnost řešit service discovery, konzistentnost, síťovou latenci a spolehlivost komunikace.
    • Vyžaduje pokročilé DevOps praktiky.

MVC (Model View Controller)

(Více viz 12 SWI - MVC)

  • Rozděluje prezentační vrstvu (data, UI a řídící logiku) na tři vzájemně propojené komponenty

  • Model - Reprezentuje data aplikace a business logiku. Je zodpovědný za správu dat, jejich validaci a operace nad nimi. Nezávisí na View ani Controlleru.

  • View (Pohled) - Zodpovídá za prezentaci dat uživateli. Získává data z Modelu (často prostřednictvím Controlleru) a zobrazuje je. Neměl by obsahovat business logiku.

  • Controller (Ovladač) - Přijímá vstupy od uživatele (z View), interpretuje je a provádí odpovídající akce. Manipuluje s Modelem (např. aktualizuje data) a vybírá View pro zobrazení odpovědi.

  • Typický tok dat

    • Uživatel interaguje s View
    • View předá akci Controlleru
    • Controller aktualizuje Model
    • Model může notifikovat View o změně (nebo Controller vybere View a předá mu data z Modelu)
    • View se aktualizuje.

../../Attachments/Pasted image 20260620140403.png

  • Příkladem je např. framework Symfony
    • Model - V Symfony kombinace Repository, Entity a případných Services
    • View - Twig šablony
    • Controller - Např. HomePageController.php

MVP (Model View Presenter)

  • Varianta MVC, která se snaží ještě více oddělit View od Modelu a zlepšit testovatelnost prezentační logiky.

  • Model - Stejná role jako v MVC.

  • View - Pasivnější než v MVC. Definuje rozhraní pro zobrazování dat a zachytávání uživatelských událostí, ale neobsahuje logiku. Deleguje zpracování událostí na Presenter.

  • Presenter - Obsahuje prezentační logiku. Reaguje na události z View, získává data z Modelu a aktualizuje View prostřednictvím jeho rozhraní. View a Model spolu napřímo nekomunikují.

  • Typický tok dat

    • Uživatel interaguje s View
    • View deleguje událost Presenteru
    • Presenter komunikuje s Modelem
    • Presenter aktualizuje View

../../Attachments/Pasted image 20260620140539.png

Aplikační návrhové vzory

Inversion of Control (IoC)

  • Řízení toku programu je přeneseno z aplikačního kódu na externí komponenty.
  • Například Event Driven Programming - programátor řeší pouze handling eventů a externí komponenta se stará o event loop a dispatching zpráv.

Dependency injection (DI)

  • Konkrétní implementace IoC

  • Závislosti (objekty, které třída potřebuje ke své funkci) nejsou vytvářeny vně třídy, ale “injektovány” externím systémem.

  • Typy

    • Constructor injection - závislosti předány jako parametry konstruktoru
    • Setter injection - závislosti jsou nastaveny pomocí veřejných setter metod
    • Interface injection - třída implementuje rozhraní s metodou pro nastavení závislosti

GRASP vzory

(Viz 12 SWI - GRASP vzory)

  • Sada principů a vzorů pro přidělování odpovědností objektům v OOP

  • Low Coupling (Nízká provázanost): Minimalizovat závislosti mezi třídami. Změna v jedné třídě by měla mít co nejmenší dopad na ostatní.

  • High Cohesion (Vysoká soudržnost): Třída by měla mít jasně definovanou, úzce související sadu odpovědností. Všechny její metody a atributy by měly směřovat k jednomu cíli.

GoF vzory

(Viz 12 SWI - GoF vzory)

  • Katalog konkrétních, osvědčených řešení

  • Poskytují hotové šablony pro řešení často se vyskytujících problémů

  • Creational

  • Behavioral

  • Structural

Databázové návrhové vzory

Active record

  • Objekt reprezentuje řádek v databázi a obsahuje jak data, tak metody pro jejich perzistenci (načítání, ukládání, mazání).
  • Logika ukládání a business logika jsou často smíšené.
$article = Article::load( 42 );
$article->title = "...";
$article->save();

../../Attachments/Pasted image 20260620143251.png

Data Mapper

  • Odděluje objektovou reprezentaci dat (entity) od logiky pro jejich mapování na databázi.
  • Mapper obsahuje logiku pro ukládání dat
  • Entity (objekty) obsahují pouze data
article = $mapper->load( 42 );
$article->title = "...";
$mapper->save( $article );

../../Attachments/Pasted image 20260620143259.png

Unit of Work / Work of Unit

  • Sleduje změny provedené na objektech během business transakce a koordinuje zápis těchto změn do databáze jako jednu atomickou operaci

  • (typicky na konci transakce pomocí metody flush())

  • Fronta změn

  • Změny se provedou najednou

$article = new Article( "..." );
$manager->persist( $article );        // add new article
$manager->remove( $article2 );        // remove from db
$manager->flush();                    // save changes into database

../../Attachments/Pasted image 20260620143316.png

REST

Representational State Transfer

  • Architektonický styl pro tvorbu aplikačních rozhraní (API)

  • Sada pravidel a doporučení, jak by měly dva systémy (např. mobilní aplikace a backendový server) komunikovat po síti pomocí protokolu HTTP

  • Client-server - Klient se stará o uživatelské rozhraní a UX, server se stará o data a business logiku.

  • Bezstavovost

    • Každý požadavek od klienta musí obsahovat všechny informace potřebné k jeho obsluze.
    • Server si neukládá žádný kontext o klientovi mezi požadavky
    • Veškerý stav relace je udržován na straně klienta.

  • Místo toho, aby server řídil tok aplikace tím, že by si uživatele vodil krok za krokem, tak server vezme data z databáze, vytvoří z nich reprezentaci (JSON) a tento stav přenese (Transfer) ke klientovi.

  • Když klient chce stav změnit (např. upravit své jméno v profilu), upraví si tuto reprezentaci u sebe a pošle kompletní nový stav zpět na server, aby si ho server uložil.

  • Zdroje (Resources) - Data, se kterými pracujeme (např. uživatel, článek, objednávka)

Manipulace se zdroji

  • Aby se tato bezstavová výměna dat dala dobře a jednotně řídit, využívá REST naplno standardní metody protokolu HTTP.

  • Adresa (URL) ukazuje na to, s čím manipulujeme, a metoda určuje, co s tím děláme:

  • GET /uzivatele: Zobrazí pole všech uživatelů.

  • GET /uzivatele/42: Zobrazí aktuální stav uživatele 42.

  • POST /uzivatele: Vytvoří nového uživatele s tímto počátečním stavem.

  • PUT /uzivatele/42: Kompletně přepíše stávajícího uživatele novým stavem.

  • DELETE /uzivatele/42: Smaže tento zdroj (a tím zruší jeho stav).

HATEOAS

Hypermedia as the Engine of Application State

  • Klient by měl být schopen navigovat aplikací a objevovat dostupné akce pouze na základě informací (hypermediálních odkazů a formulářů) obsažených v reprezentacích zdrojů vrácených serverem.

  • Server vede klienta skrze možné stavy aplikace pomocí odkazů.

  • To umožňuje serveru vyvíjet API nezávisle na klientovi.

  • Implementace

    • Typicky se realizuje vkládáním odkazů do JSON nebo XML odpovědí.
    • Každý odkaz má URI (href), vztah (rel - popisuje sémantiku odkazu) a případně další atributy (např. podporované metody).

  • Příklad:

    • Klient si vyžádá detail objednávky pomocí GET /orders/123
    • Server vrátí reprezentaci objednávky
    • Klíčové je, že odpověď obsahuje i sekci _links (nebo podobnou, je to konvence), která klientovi říká, co může dál dělat.
{
  "id": 123,
  "status": "awaiting_payment",
  "total_price": "1500",
  "currency": "CZK",
  "items":,
  "_links": {
    "self": {
      "href": "/orders/123",
      "method": "GET"
    },
    "pay": {
      "href": "/orders/123/payment",
      "method": "POST",
      "description": "Provést platbu objednávky."
    },
    "cancel": {
      "href": "/orders/123/cancellation",
      "method": "POST",
      "description": "Zrušit objednávku."
    },
    "customer": {
      "href": "/customers/56"
    }
  }
}

Vytvořeno: 20. 6. 2026, 22:38
Poslední aktualizace: 20. 6. 2026, 23:46