Webové technologie

Protokoly

Síťový protokol je sada pravidel, která určují, jak spolu zařízení v síti komunikují. Webové protokoly tvoří páteř internetu – bez nich by prohlížeč nevěděl, jak si říct serveru o stránku, jak ji bezpečně přenést, ani jak udržet obousměrnou komunikaci v reálném čase.

HTTP

HTTP (HyperText Transfer Protocol) je bezstavový protokol na úrovni aplikační vrstvy TCP/IP modelu. Slouží k přenosu hypertextových dokumentů (HTML, CSS, JS, obrázky, JSON, XML a další data) mezi klientem (typicky prohlížeč) a serverem. HTTP funguje na principu požadavek–odpověď: klient pošle požadavek a server na něj odpoví.

GET /api/user?id=42 HTTP/1.1
Host: example.com
Accept: application/json
Cookie: session=abc123

HTTP/1.1 200 OK
Content-Type: application/json
Set-Cookie: session=xyz789; HttpOnly; Secure
Content-Length: 85

{"id": 42, "name": "Jan Novák", "email": "jan@example.com"}

HTTP metody

HTTP metody (někdy nazývané slovesa) říkají serveru, jakou operaci chce klient s daným zdrojem provést.

Stavové kódy

Stavový kód je tříciferné číslo, které server vrací jako součást odpovědi. První cifra určuje kategorii:

Verze HTTP

HTTP protokol prošel za dobu své existence několika zásadními revizemi. Každá verze přinesla změny ve výkonu, způsobu navazování spojení a efektivitě přenosu dat.

HTTP/0.9 (1991)

Původní protokol navržený Timem Berners-Leem. Extrémně jednoduchý – podporoval pouze metodu GET, neobsahoval hlavičky ani stavové kódy. Server po přijetí požadavku odpověděl čistě HTML obsahem a spojení ihned uzavřel.

GET /index.html

Odpovědí bylo přímo HTML – bez jakýchkoliv metadat. Pro tehdejší potřeby sdílení statických dokumentů to stačilo, ale jakékoliv rozšíření by znamenalo zásadní změnu protokolu.

HTTP/1.0 (1996)

První standardizovaná verze, která přinesla hlavičky, stavové kódy, a podporu metod HEAD a POST. Každý požadavek však znamenal nové TCP spojení – po odeslání odpovědi se spojení zavřelo.

HTTP/1.1 (1997)

Zavedl trvalé spojení (keep-alive) jako výchozí chování – jedno TCP spojení je znovupoužito pro více požadavků. Přidal pipelining (teoreticky umožňující poslat více požadavků bez čekání na odpovědi), hlavičku Host (umožňující virtuální hosting), a podporu pro částečné stahování (range requests).

HTTP/2 (2015)

Přinesl zásadní architektonickou změnu – multiplexing více požadavků a odpovědí v rámci jednoho TCP spojení pomocí tzv. streamů. Každý stream je označen identifikátorem a data se prokládají v rámcích (frames), takže pomalý požadavek už neblokuje ostatní. Dále přidal:

• Kompresi hlaviček (HPACK) – hlavičky se posílají binárně a pomocí slovníkové komprese se vyhne opakování stejných hodnot.
• Server Push – server může klientovi poslat zdroje ještě předtím, než si o ně řekne (např. CSS soubory odkazované z HTML).
• Prioritizaci streamů – klient může serveru naznačit, které zdroje potřebuje dříve.

HTTP/3 (2022)

Největší změna od vzniku protokolu. HTTP/3 opouští TCP a staví na protokolu QUIC, který běží nad UDP. Důvodem je odstranění head-of-line blocking i na transportní vrstvě – TCP totiž z principu vyžaduje doručení paketů v pořadí, takže ztráta jednoho TCP paketu zablokuje celý stream, i když se týká úplně jiného zdroje. QUIC tento problém řeší tím, že každý stream je v rámci UDP spojení nezávislý.

Cookies

Cookies jsou malé textové soubory, které server ukládá na straně klienta (v prohlížeči) a které klient automaticky posílá zpět při každém dalším požadavku na stejný server. Protože HTTP je ze své podstaty bezstavový protokol (každý požadavek je nezávislý), cookies slouží jako mechanismus pro udržení stavu – např. přihlášení uživatele, obsah nákupního košíku, jazykové preference nebo analytické identifikátory.

Typy cookies podle životnosti

• Session cookies (relační): Nemají nastaveno Max-Age ani Expires. Existují jen po dobu otevřeného prohlížeče – po jeho zavření se smažou. Používají se pro přihlašovací relace.
• Persistent cookies (trvalé): Mají nastavenou dobu platnosti. Zůstávají uložené i po zavření prohlížeče. Používají se např. pro zapamatování jazykových preferencí, souhlasu s cookies, nebo pro analytiku.
• Supercookies: Nejsou to klasické HTTP cookies – jedná se o metody sledování využívající hlavičky, mezipaměti nebo jiné mechanismy, které nepodléhají standardním omezením. Zahrnují například Evercookie, HSTS Supercookie nebo zombie cookies. Obecně jsou tyto techniky považovány za narušení soukromí a prohlížeče je aktivně blokují.

Typy cookies podle účelu

• Nezbytně nutné: Vyžadované pro základní funkčnost webu (např. session cookie pro přihlášení).
• Funkční: Umožňují zapamatovat si volby uživatele (jazyk, region, přihlašovací jméno).
• Analytické: Slouží pro sběr anonymizovaných dat o návštěvnosti a chování pro statistiku.
• Marketingové: Sledují uživatele napříč weby za účelem cílení reklamy (tzv. 3rd-party cookies, postupně omezovány).
• Preferenční: Uchovávají preference, jako je tmavý/světlý režim, velikost písma, rozložení stránky.

// Nastavení bezpečné session cookie na 24 hodin
setcookie("session_id", "a1b2c3d4", [
    "expires" => time() + 86400,
    "path" => "/",
    "domain" => "example.com",
    "secure" => true,
    "httponly" => true,
    "samesite" => "Lax"
]);

Cross-site request forgery (CSRF)

CSRF je útok, při kterém útočník přiměje přihlášeného uživatele k provedení nechtěné akce na webu, kde je uživatel autentizován. Zneužívá toho, že prohlížeč automaticky posílá cookies s každým požadavkem na danou doménu.

Cross-site scripting (XSS)

XSS je útok, při kterém útočník vloží škodlivý kód (typicky JavaScript) do stránky, která je následně zobrazena ostatním uživatelům. Na rozdíl od CSRF, který zneužívá automatické posílání cookies, XSS útočí na samotné zobrazení obsahu.

Third-party cookies a jejich konec

Third-party cookies jsou cookies nastavené jinou doménou, než kterou uživatel aktuálně navštívil – typicky přes vložené prvky jako reklamní bannery, trackovací pixely nebo iframe.

Cross-site leakage

Cross-site leakage je kategorie útoků, při kterých útočník získává informace o jiné webové stránce pomocí tzv. bočních kanálů (side channels) – tedy pozorováním chování prohlížeče, nikoliv přímým čtením dat. Na rozdíl od XSS nebo CSRF zde útočník nemusí vložit škodlivý kód na cílový web – stačí, když oběť navštíví útočníkův web, zatímco je přihlášená na cílovém webu.

Typické postranní kanály zahrnují:

• Časování: Měření doby trvání požadavku může prozradit, zda odpověď pochází z cache nebo zda je uživatel administrátor.
• Detekce chyb: Různé stavové kódy nebo hlavičky prozrazující, zda zdroj existuje nebo je přístupný.
• Cache probing: Zjišťování, zda je zdroj v mezipaměti prohlížeče (a tedy ho uživatel navštívil), pomocí měření doby načítání.
• CSS-based leakage: Škodlivý CSS styl aplikuje pozadí z externí URL na prvek :visited a detekuje, jestli prohlížeč provedl síťový požadavek.
• XS-Leaks (Cross-Site Leaks): Konkrétní techniky zneužívající window.length, postMessage timing, detekci scrollbaru, nebo iframe počet framů pro odhad obsahu response.

HTTPS

HTTPS (HyperText Transfer Protocol Secure) je HTTP provozovaný přes šifrované spojení pomocí protokolu TLS (Transport Layer Security, dříve SSL). HTTPS zajišťuje tři klíčové vlastnosti:

1. Důvěrnost (confidentiality): Data jsou šifrovaná – nikdo mezi klientem a serverem nemůže komunikaci číst.
2. Integritu (integrity): Data nelze během přenosu nepozorovaně změnit.
3. Autenticitu (authenticity): Klient si ověří, že komunikuje se skutečným serverem, ne s podvrhem.

WebSocket

WebSocket je protokol (definovaný v RFC 6455), který umožňuje plně duplexní, obousměrnou komunikaci mezi klientem a serverem přes jediné TCP spojení. Na rozdíl od HTTP, kde klient vždy iniciuje komunikaci a server pouze odpovídá, WebSocket umožňuje serveru aktivně posílat data klientovi kdykoliv – bez čekání na požadavek.

Architektura webové služby

Webová služba je softwarový systém navržený pro interoperabilní komunikaci mezi různými aplikacemi přes síť. Tři hlavní architektury – SOAP, REST a JSON-RPC – se liší filozofií, formátem dat i způsobem přenosu.

SOAP

SOAP (Simple Object Access Protocol) je protokol pro výměnu strukturovaných informací v decentralizovaném, distribuovaném prostředí. Využívá XML pro formát zpráv a může být přenášen přes různé transportní protokoly (nejčastěji HTTP, ale i SMTP, TCP nebo JMS). SOAP je standardizován konsorciem W3C.

Struktura SOAP zprávy

Každá SOAP zpráva je XML dokument s kořenovým elementem Envelope, který obsahuje:

<?xml version="1.0" encoding="UTF-8"?>
<soap:Envelope xmlns:soap="http://www.w3.org/2003/05/soap-envelope">
    <soap:Header>
        <!-- Metadata: autentizace, transakce, směrování -->
        <auth:Token xmlns:auth="https://api.example.com/auth">
            Bearer eyJhbGciOiJIUzI1NiIs...
        </auth:Token>
    </soap:Header>
    <soap:Body>
        <!-- Tělo zprávy: samotná data -->
        <GetUserRequest xmlns="https://api.example.com/users">
            <UserId>42</UserId>
        </GetUserRequest>
    </soap:Body>
    <soap:Fault>
        <!-- Chybový stav (volitelné) -->
    </soap:Fault>
</soap:Envelope>

WSDL dokument

WSDL (Web Services Description Language) je XML formát, který popisuje veřejné rozhraní webové služby – jaké operace jsou dostupné, jaké mají parametry, jak formátovat požadavky a kde služba běží.

<?xml version="1.0" encoding="UTF-8"?>
<definitions name="UserService"
             targetNamespace="https://api.example.com/users"
             xmlns:tns="https://api.example.com/users"
             xmlns:xsd="http://www.w3.org/2001/XMLSchema"
             xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"
             xmlns="http://schemas.xmlsoap.org/wsdl/">

    <!-- Datové typy (XSD schéma) -->
    <types>
        <xsd:schema targetNamespace="https://api.example.com/users">
            <xsd:element name="User">
                <xsd:complexType>
                    <xsd:sequence>
                        <xsd:element name="Id"    type="xsd:int"/>
                        <xsd:element name="Name"  type="xsd:string"/>
                        <xsd:element name="Email" type="xsd:string"/>
                    </xsd:sequence>
                </xsd:complexType>
            </xsd:element>
        </xsd:schema>
    </types>

    <!-- Abstraktní definice operací -->
    <message name="GetUserRequest">
        <part name="UserId" type="xsd:int"/>
    </message>
    <message name="GetUserResponse">
        <part name="User" element="tns:User"/>
    </message>

    <portType name="UserPortType">
        <operation name="GetUser">
            <input  message="tns:GetUserRequest"/>
            <output message="tns:GetUserResponse"/>
        </operation>
    </portType>

    <!-- Konkrétní binding na SOAP přes HTTP -->
    <binding name="UserBinding" type="tns:UserPortType">
        <soap:binding style="document"
                      transport="http://schemas.xmlsoap.org/soap/http"/>
        <operation name="GetUser">
            <soap:operation soapAction="https://api.example.com/users/GetUser"/>
            <input>  <soap:body use="literal"/></input>
            <output> <soap:body use="literal"/></output>
        </operation>
    </binding>

    <!-- Koncový bod služby -->
    <service name="UserService">
        <port name="UserPort" binding="tns:UserBinding">
            <soap:address location="https://api.example.com/soap/users"/>
        </port>
    </service>
</definitions>

UDDI

UDDI (Universal Description, Discovery and Integration) je adresářový mechanismus pro SOAP webové služby – funguje jako „zlaté stránky" pro webové služby. Jeho účelem je umožnit organizacím publikovat, vyhledávat a dynamicky navazovat SOAP služby bez nutnosti předem znát jejich umístění.

SOAP vs. REST

REST

REST (Representational State Transfer) je architektonický styl pro návrh distribuovaných systémů, který v roce 2000 definoval Roy Fielding ve své disertační práci. REST není protokol ani standard, ale soubor principů a omezení, které při dodržení vedou k systému, který je škálovatelný, bezstavový, cacheovatelný a má jednotné rozhraní.

Principy

RESTful je termín, který označuje API nebo webovou službu, která skutečně dodržuje REST principy. Ne každé HTTP API je RESTful – mnoho API se označuje za REST, i když splňuje jen část omezení (typicky jen používá HTTP metody a JSON).

Pojmy

GET /users/42 HTTP/1.1
Host: api.example.com
Accept: application/json

{
    "id": 42,
    "name": "Jan Novák",
    "email": "jan@example.com",
    "created_at": "2025-03-15T10:30:00Z"
}

GET /users/42 HTTP/1.1
Host: api.example.com
Accept: application/xml

<?xml version="1.0" encoding="UTF-8"?>
<user>
    <id>42</id>
    <name>Jan Novák</name>
    <email>jan@example.com</email>
    <created_at>2025-03-15T10:30:00Z</created_at>
</user>

Návrh

Dobře navržené REST API používá podstatná jména (ne slovesa) a hierarchickou strukturu URI, kde HTTP metody určují operaci.

GET     /users              # Seznam všech uživatelů (kolekce)
POST    /users              # Vytvoření nového uživatele
GET     /users/42           # Detail uživatele s ID 42
PUT     /users/42           # Nahrazení celého uživatele 42
PATCH   /users/42           # Částečná úprava uživatele 42
DELETE  /users/42           # Smazání uživatele 42
GET     /users/42/orders    # Objednávky uživatele 42
GET     /users/42/orders/7  # Objednávka č. 7 uživatele 42

HATEOAS

HATEOAS (Hypermedia As The Engine Of Application State) je princip, podle kterého server v odpovědi poskytuje odkazy na další možné akce, které může klient se zdrojem provést. Klient tak nemusí mít natvrdo zakódované URL cesty – řídí se tím, co mu server nabídne.

{
    "id": 42,
    "name": "Jan Novák",
    "email": "jan@example.com",
    "_links": {
        "self": { "href": "/users/42" },
        "orders": { "href": "/users/42/orders" },
        "deactivate": { "href": "/users/42/deactivation", "method": "POST" },
        "update": { "href": "/users/42", "method": "PATCH" }
    }
}

HAL (Hypertext Application Language)

HAL je minimalistický formát pro reprezentaci zdrojů s hypermédii. Rozděluje JSON odpověď na dvě jasné sekce: _links (odkazy) a _embedded (vnořené zdroje). Je to jeden z nejjednodušších a nejpoužívanějších HATEOAS formátů.

{
    "id": 42,
    "name": "Jan Novák",
    "_links": {
        "self": { "href": "/users/42" },
        "orders": { "href": "/users/42/orders" },
        "deactivate": { "href": "/users/42/deactivation" }
    },
    "_embedded": {
        "recentOrders": [
            {
                "_links": { "self": { "href": "/orders/105" } },
                "total": 1250.50,
                "status": "delivered"
            }
        ]
    }
}

Siren

Siren je robustnější hypermediální formát, který kromě odkazů definuje i akce (actions) – tedy operace, které klient může provést, včetně jejich metody, parametrů a očekávaných datových typů. To HAL neumí – ten odkazuje jen na URI.

{
    "class": ["user"],
    "properties": {
        "id": 42,
        "name": "Jan Novák"
    },
    "links": [
        { "rel": ["self"], "href": "/users/42" }
    ],
    "actions": [
        {
            "name": "update-name",
            "title": "Změnit jméno",
            "method": "PATCH",
            "href": "/users/42",
            "type": "application/json",
            "fields": [
                { "name": "name", "type": "text" }
            ]
        }
    ]
}

Verzování

Protože REST API se v čase vyvíjí, je potřeba řešit zpětnou kompatibilitu:

Formáty odpovědí

JSON:API

JSON:API je standardizovaný formát pro REST API odpovědi, který definuje jednotnou strukturu pro reprezentaci zdrojů, vztahů mezi nimi, chyb a metadat. Je to pokus o standardizaci toho, co REST standard sám od sebe nedefinuje.

{
    "data": {
        "type": "articles",
        "id": "1",
        "attributes": {
            "title": "REST API design",
            "body": "Lorem ipsum..."
        },
        "relationships": {
            "author": {
                "data": { "type": "people", "id": "9" },
                "links": {
                    "related": "/articles/1/author"
                }
            },
            "comments": {
                "links": {
                    "related": "/articles/1/comments"
                }
            }
        },
        "links": {
            "self": "/articles/1"
        }
    },
    "included": [
        {
            "type": "people",
            "id": "9",
            "attributes": {
                "name": "Jan Novák"
            }
        }
    ],
    "errors": [],
    "meta": {
        "copyright": "© 2025 Example Corp."
    },
    "jsonapi": {
        "version": "1.1"
    }
}

OpenAPI specifikace

OpenAPI (dříve Swagger) je standard pro popis REST API – ekvivalent WSDL pro REST svět. Na rozdíl od WSDL, který je povinný pro SOAP, je OpenAPI dobrovolné. Definuje endpointy, parametry, formáty požadavků a odpovědí, autentizační schémata a další.

openapi: "3.1.0"
info:
  title: User API
  version: "1.0.0"
  description: API pro správu uživatelů
servers:
  - url: https://api.example.com/v1
paths:
  /users:
    get:
      summary: Seznam uživatelů
      parameters:
        - name: page
          in: query
          schema:
            type: integer
            default: 1
      responses:
        "200":
          description: Úspěšný seznam
          content:
            application/json:
              schema:
                type: array
                items:
                  $ref: "#/components/schemas/User"
    post:
      summary: Vytvoření uživatele
      requestBody:
        required: true
        content:
          application/json:
            schema:
              $ref: "#/components/schemas/CreateUserRequest"
      responses:
        "201":
          description: Uživatel vytvořen
  /users/{userId}:
    get:
      summary: Detail uživatele
      parameters:
        - name: userId
          in: path
          required: true
          schema:
            type: integer
      responses:
        "200":
          description: Detail uživatele
          content:
            application/json:
              schema:
                $ref: "#/components/schemas/User"
        "404":
          description: Uživatel nenalezen
components:
  schemas:
    User:
      type: object
      properties:
        id:
          type: integer
        name:
          type: string
        email:
          type: string
          format: email
    CreateUserRequest:
      type: object
      required: [name, email]
      properties:
        name:
          type: string
        email:
          type: string
          format: email

JSON-RPC

JSON-RPC je odlehčený protokol pro vzdálené volání procedur (RPC) využívající JSON. Vznikl jako jednoduchá alternativa k XML-RPC a SOAPu. Na rozdíl od RESTu, který je orientovaný na zdroje, JSON-RPC je orientovaný na volání funkcí/procedur.

{
    "jsonrpc": "2.0",
    "method": "subtract",
    "params": [42, 23],
    "id": 1
}

{
    "jsonrpc": "2.0",
    "result": 19,
    "id": 1
}

{
    "jsonrpc": "2.0",
    "error": {
        "code": -32601,
        "message": "Method not found"
    },
    "id": 1
}

[
    { "jsonrpc": "2.0", "method": "getUser", "params": {"id": 42}, "id": 1 },
    { "jsonrpc": "2.0", "method": "getUser", "params": {"id": 43}, "id": 2 },
    { "jsonrpc": "2.0", "method": "deleteUser", "params": {"id": 99}, "id": 3 }
]

Shrnutí: Kdy použít kterou architekturu