2 Distribuované systémy

tags: `řvss` `distribuovane-systemy`

Definica statnicovej otazky:
Distribuované systémy. Základní pojmy, principy. Rozdíl mezi centrickou a distribuovanou architekturou systému. Virtualizace, horizontální/vertikální škálovatelnost. Data sharding, high-availability. Příklady existujících technologií a jejich využití. Webové služby, příklad implementace (SOAP/WSDL/REST). (PA053)

https://docs.google.com/document/d/1z98Bjw-QU8oOkzaertzWWqUyK55P-vhbSJmMmxgnIsU/edit#

Distribuovane systemy (DS)

Distribuovane systemy sa skladaju z ucastnikov (pocitace) ktori su spojeni (siet). Aby tieto pocitace boli schopne medzi sebou koordinovat cinnost, zdielat dostupne zdroje a vyuzivat sluzby poskytovane jednotlivymi ucastnikmi, potrebujeme spolocnu vrstvu - middleware.

Vdaka tomuto prepojeniu su distribuovane systemy riesenim na vykonavanie velkych vypocetnych uloh, kde uzivatel ma specificke poziadavky (napr. velke mnozstvo CPU).

DS sa vyznacuje vlastnostami:

musi tolerovat poruchy jednotlivych ucastnikov
struktura systemu nie je dopredu znama (napr. pocet ucatnikov, topologia siete, OS ucastnikov) a moze sa pocas casu menit
kazdy ucastnik ma obmedzeny pohlad na system

Rozlisujeme rozne architektury DS:

monolithic architecture
- je samostatna pretoze obsahuje vsetko, co potrebuje no zaroven je tazkopadna
- nemodularna, neda sa pouzit znova, tazko sa udrzuje, neskaluje
tiered architecture
- jednotlive "tiers" mozu byt distribuovane, prebieha paralelizacia na urovni "tier"
- jednotlive "tiers" maju nezavislu implementaciu a tak mozu byt lahko menene (casto su definovane cez API)
- patria tu client/server modely
  - one-tier architecture (thin client - vsetok load na servri, ktory tak predstavuje SPOF)
  - two-tier architecture (thick client - cast loadu je i na klientovi, no toto prepojenie vyzaduje tight coupling)
  - three(+)-tier architecture - zvysuje skalovatelnost a spolahlivost, no je to uz prilis komplexna architektura
component-based architecture
- komponenta je reprezentovana softwarovym balikom, ktory poskytuje istu funkcionalitu
- interna implementacia je skryta, balik vystavuje iba API
- Replaceable, reusable
service-oriented architecture (SOA)
- aplikacia je zlozena z viacerych nezavislych sluzieb, ktore vystavuju interfaces ktore sa musi na seba pripajat
- je to plne distribuovana architektura, ale vyzaduje orchestraciu a moze sa stat, ze celkovo cela sluzba nebude dostupna kvoli chybe jednej casti systemu
microservices architecture
- moderny podtyp SOA kde aplikacia je zlozena z microservices - male enzavisle sluzby, specializovane na jednu cinnost
- vyznacuje sa low-coupling, lightweight komunikaciou, zmena microservice neovplyvni nikoho dalsieho
peer-to-peer architecture
- Peery sa spravaju ako klienti aj ako servre (napr. distributed storage, kde data mozu vsetci ukladat ale aj ziadat, zvysuje sa odolnost)
shared-nothing arhcitecture
- nody su samostatne a nezavisle (nazyvaju sa aj shards), nic nie je realne zdielane, kazdy request je splneny prave jednym nodom
pocitanie v cloude
- Computing “on-demand”, kde na poziadanie ziska uzivatel potrebne zdroje alokovane z dopredu dedikovanych zdrojov
- rozlisujeme tu vertikalne/horizontalne skalovanie (bude neskor)

Middleware

Middleware ma viac definicii, niektore su nejasne:

Middleware is the slash in Client/Server
no mohli by sme ho popisat ako:
Middleware is a general term for any programming that serves to "glue together" or mediate between two separate and often already existing programs

Middleware je software, ktory prepaja softwarove komponenty. Lezi medzi OS a aplikaciami na kazdej strane distribuovanej PC siete kde implementuje nejaku spolocnu funkcionalitu aby aplikacie mohli spolupracovat (rozne abstrakcie, webove sluzby, OO metody).

Pouzitie middlewaru zvysuje dostupnost aplikacie (ma vyssiu odolnost proti chybam), zvysuje pouzitelnost aplikacie (interoperabilita ponuka funkcnost aj externym aplikaciam), dekomponuje funkcionalitu (jednoduchsi vyvoj a testovanie)

Image Not Showing Possible Reasons

The image file may be corrupted
The server hosting the image is unavailable
The image path is incorrect
The image format is not supported

Learn More →

Rozdiel medzi centrickou a distribuovanou architekturou systemu

Centricke systemy:

definuju mensi pocet servrov/miest, kde sa pripajaju ostatni ucastnici aby ziskali informacie alebo vykonali cinnost
typicky obsahuju male mnozstvo centralnych prvkov a velke mnozstvo klientov => centricka architektura
je nachylnejsia na problemy pretoze obsahuje mensie mnozstvo nodov, ktore zazivaju vacsi napor (od tolkych klientov)
napriklad database-centric architektury v ktorych databazy kraju klucovu rolu a k databazam sa pripajaju ostatne sluzby (e.g., datove banky genomov)

Distribuovane systemy:

definuju kolekciu samostatnych nezavislych komponent ktore su ale spojene v jeden celkok (nejakym sposobom, napr cez siet) a tak pracuju na spolocnom cieli
distribuovany system sa bude zdat uzivatelovi ako jeden interface
cielom je predchadzat zlyhaniam a maximalizovat vyuzitie zdrojov
prikladom je Internet, kde jednotlive PC su schopne medzi sebou posielat spravy pomocou specifikovania IP adresy. Patria sem peer-to-per networks (torrenty)

Virtualizace, horizontální/vertikální škálovatelnost

Virtualizacia vytvara simulovane vypocetne prostredie, v ktorom vytvarame pocitacove kopie zdrojov (napr. pamat, procesor, disk). Pretoze kopie vznikaju iba ako koncepty, hovorime o virtualnych objektoch - mame virtualnu pamat, virtualny disk, … V konecnom dosledku sme schopni poskytnut uzivatelovi cely virtualny pocitac. Uzivatel ma uplnu kontrolu nad celym virtualnym pocitacom no v skutocnosti vsak zdiela fyzicke zdroje s dalsimi uzivatelmi.

Tento koncept umoznuje organizaciam disponujucim zdrojmi rozdelit pocitac alebo server na niekolko virtualnych PC, kde kazdy moze pracovat nezavisle a spustat rozne OS ci aplikacie, zatial co sa zdielaju zdroje jedneho hostitelskeho PC.

Vyhody virtualizacie:

vytvara viac prostriedkov z jedneho zdroja a tym zlepsuje skalovatelnost
vdaka lepsej skalovatelnosti znizuje celkovy pocet vyuzivanych servrov, spotrebu energie, naklady na infrastrukturu
lahka migracia
dokonale testovacie prostredie

Urovne servrovej virtualizacie

Kontajnerizacia
- virtualizaica na urovni OS kde sa vytvaraju oddelene prostredia - namespacy - pre beh procesov
- napr. chroot, OpenVZ, Docker
  Image Not Showing Possible Reasons
  The image file may be corrupted
  The server hosting the image is unavailable
  The image path is incorrect
  The image format is not supported
  Learn More →
Emulacia
- umoznuje provozovat na hostujucom systeme virtualny system inej architektury
- aby sa toto dosiahlo, vsetky vykonavane operacie v hostujucom systeme sa musia interpretovat, co ma za nasledok znizenie vykonu
- emulacia moze byt zalozena na interpretacii, statickom preklade alebo dynamickom preklade
- napr. dynamicky emulator QEMU ci Rosetta na MAC notebookoch pre interpretaciu INTEL architektury
  Image Not Showing Possible Reasons
  The image file may be corrupted
  The server hosting the image is unavailable
  The image path is incorrect
  The image format is not supported
  Learn More →
Paravirtualizacia
- Ak sa niektore komponeny virtualneho a fyzickeho PC zhoduju (napr. hostujuci system ma rovnaky procesor), pouzivame paravirtualizaciu, ktora vykonava iba ciastocnu abstrakciu na urovni virtualneho PC; HW nie je virtualizovany
- pristupy k HW su prevedene na volanie hypervizora (=typ emulatoru)
- hostovany system vie, ze bezi vo virtualnom prostredi a dokaze efektivne komunikovat s hypervizorom
- napr. VMware, Xen, KVM
  Image Not Showing Possible Reasons
  The image file may be corrupted
  The server hosting the image is unavailable
  The image path is incorrect
  The image format is not supported
  Learn More →
Plna virtualizacia
- nastava ak sa virtualizuju vsetky casti PC
- vyzaduje, aby hostovany i hostujuci system mali rovnaku architekturu pretoze pre hostovany system sa vytvara identicky obraz fyzicke architektury
- hostovany system nevie, ze bezi vo virtualnom prostredi
- napr. VMware, VirtualBox, Mac-on-Linux
  Image Not Showing Possible Reasons
  The image file may be corrupted
  The server hosting the image is unavailable
  The image path is incorrect
  The image format is not supported
  Learn More →

Typy virtualizacie

Data virtualisation
- prezentacia dat ako abstraktna vrstva nezavisla na zakladnych DB systemoch strukturach, ulozisti
- postavene na principe LVM = logical volume management
Desktop virtualisation
- setri naklady na spravu distribuovaneho prostredia, v ktorom bezia aplikacie, zvysuje bezpecnost firemnych dat pretoze vsetky data mozu byt centralizovane
- napr. VMware View alebo REmote Desktop Service na Windows servroch
Server virtualisation
- prakticky zvysuje vyuzitie servrov vytvaranim virtualnych PC na fyzickych servroch
- popisane vyssie
OS virtualisation
- vyuziva pre svoj beh jadro OS
- napr. OpenVZ
Network virtualisation
- kombinuje HW a SW sietove zdroje a sietovu funkcionalitu vo vytvorenie jednej virtualnej siete
- napr. OpenVPN

Skalovatelnost

Skalovatelnost je ziaduca vlastnost systemu, siete alebo procesu reagovat na a zvladnut nahle zmeny v potrebach obsluhy. Moze odkazovat ako na zvysovanie zdrojov v pripade potreby (napr. pridanie HW) tak aj na hospodarnost ak vysoky vykon nie je potrebny.

Skalovatelnost je dolezita pri poskytovani pristupu mnohym uzivatelom naraz, pri spracovani rastuceho mnozstva dat bez straty vykonu a s prijatelnym oneskorenim.

Priklady

U webového serveru, který zajišťuje hlasování do televizní soutěže, předpokládáme, že po skončení pořadu se na náš server připojí několikanásobně více uživatelů než běžně
Schopnost mobilní sítě vydržet předpokládanou špičku v zasílání SMS zpráv na silvestra krátce před půlnocí.
Ako škálovatelná se označují (hardwarová, softwarová, jiná) řešení, která se principielně neliší v závislosti na uspokojovaných požadavcích, například různé databázové systémy

Horizontalna skalovatelnost

Znamena pridanie alebo ubranie prvkov systemu (kvantitativna zmena) ako napr. pridanie noveho PC do distribuovaneh SW aplikacie, pridanie servru do clustru.

Priklad
Pretoze ceny pocitacov klesli a vykon narastol, vysoko vykonne pocitacove aplikacie ako napr. fyzikalne vypocty dokazu vyuzivat lacnejsie systemy. Systemovi architekti ich vedia nakonfigurovat a pospajat tak, aby suhrnne dosiahli pozadovany (a casto aj vacsi) vypocetny vykon.

Vertikalna skalovatelnost

Znamena zmenu vlastnosti aktualnych prvkov systemu (kvalitativna zmena) cize pridanie/odobranie prostriedkov do aktualnych uzlov systemu, napr. pouzitie vykonejsej CPU. Taketo sklaovanie efektivnejsie vyuziva virtualizacnu technologiu preotze poskytuje viac zdrojov pre hostitelsku sadu OS.

Medzi oboma modelmi existuju kompromisy. Viac pocitacov znamena zvysenu zlozitost spravy a prinasa so sebou aj zlozitejsie problemy, napr. vyriesenie priepustnosti a latencie medzi uzlami. Horizontalne skalovanie taktiez kladie vysoke naroky na vyvojarov, od ktorych sa ockava vytvaranie aplikacii pripravenych na pralaleny beh. Pisanie takychto aplikacii je vyrazne narocnejsie na znalosti, cas i testovanie.

Horizontalne sa skaluje napr. v MongoDB (databaza je ulozena na viacerych servroch), vertikalne v MySQL (kupi sa lepsi HW, ktory bude rychlejsi).

Data sharding, high-availability

Sharding

Sharding je databazovy architekturny vzor, ktory suvisi s horizontalnym delenim - technika delenia riadkov databazovych tabuliek do viacerych odlisnych tabuliek = partitions

Sharding deli data do dvoch (alebo viacerych) mensich dielov nazyvanych logical shards. Tie su potom distribuovane na samostante nody, ktorym sa hovori physical shards. Dokopy, data ulozene vo vsetkych shardoch tvoria cely logicky dataset.

Data sharding predstavuje typicky shared-nothing architektutu - shardy su autonomne, nezdielaju rovnake data ani vypocetne zdroje.

Vyhody

Sharding znizuje pocet riadkov v tabulkach kedze riadky su rozdelene a distribuovane na viacerych servrich. To znizuje velkost indexu co vseobecne zlepsuje vykon vyhladavania. Sharding zvysuje odolnost voci vypadku kedze je pravdepodobne, ze vypadok zasiahne iba jedne fyzicky ci logicky shard a tak vacsina je dat je stale dostupna.

Nevyhody

Sharding je silnejsie spolieha na prepojenie medzi servrami a ak query vyhladava vo viac ako jednom sharde, zvykneme pozorovat zvysenu latenciu. Problemom moze byt aj eventualny disbalans shardov kde jeden moze byt ovela vacsi nez ine (napr. rozdelujeme zakaznikov podla mena do tabuliek A-M, N-Z a z nejakeho dovodu mame 5x viac ludi s menami A-M a teda tento shard bude ovela vacsi)

High-availability

Vysoka dostupnost je charakteristika systemu, ktoreho cielom je zaistit dohodnutu uroven provozneho vykonu a dostupnosti, ktora je obykle vyssia nez je zvycajne.

Modernizacia vyustila vo zvysenu zavislost na tychto systemoch, napr. nemocnice ci datove centra vyzaduju vysoku dostupnost svojich systemov. Dostupnost sa tyka schopnosti uzivatelskej komunity ziskat sluzby, ziskat pristup, vykonat akukolvek operaciu (GET, PUT, UPDATE). Ak uzivatel nema pristup do systemu, je z jeho pohladu nedostupny. Termin prestoj sa pouziva k oznaceniu obdobia, ked je system nedostupny.

V konstrukcii spolahlivosti existuju 3 principy navrhu systemu, ktore mozu pomoct dosiahnut vysoku dostupnost:

eliminacia SPOF pomocou pridania redundancie do systemu (aby zlyhanie komponenty neznamenalo zlyhanie celeho systemu)
spolahlivy prechod - v redundantnych systemoch sa prechodovy bod stava SPOF. Spolahlive systemy musia zaistit spolahlivy prechod
zistenie poruch pri vyskyte - ak su dodrzane principy 1+2, potom uzivatel nemusi nikdy vidiet chybu ale udrzba musi

Dostupnost

Dostupnost systemu sa pocita ako uptime/celkovy cas, uptime = system je dostupny a funkcny. Dostuponst ovplyvuje downtime, co je cas kedy je system nedostupny. Praktickejsie definicia je (celkovy cas - downtime)/ celkovy cas. Downtime sa moze delit na:

planovany (restart, upgrade SW/HW)
neplanovany (porucha, bezpecnostne narusenie, nedostupnost siete, vypadok napajanie)
Blizkym konceptom je v oblasti databazi a ulozisk MTTF (mean time to fail -> uptime) = cas medzi dvomi poruchami disku, a MTTR (mean time to recover -> downtime) = cas pre zotavenie z poruchy.

Meranie dostupnosti

Dostupnost sa najcastejsie meria pomocou deviatok (Nines), co je dostupnost ako percento dostupnosti podla vzorca

c l a s s o f n i n e s = ⌊ - l o g_{10} x ⌋

; x = system's unavailability

Deviatky maju 7 tried, kde cislo triedy udava pocet '9' v dostupnosti (1=90%, 2=99%, 3=99.9%, …, 7=99.99999%) a udava sa aj maximalny mozny cas nedostupnosti pre danu triedu. Zvycajne sa pozaduje 5 deviatok, tieto poziadavky su uvedene v SLA (service level agreement).

Příklady existujících technologií a jejich využití

Tu neviem ake konkretne technologie chcu vediet tak vymenujem vsetko, co sa spomina v slajdoch

RPC - Sun's RPC, CORBA, .NET Remoting, SOAP
Messaging - Java ActiveMQ, MPI (v high-performance computing)
Cloud - infrasrtuktura CESNET
Service Models
- IaaS - Amazon EC2, Azure
- PaaS - Google App Engine
- SaaS - Office 365, Gmail
Big Data
- Apache Storm, Hadoop, Grid computing

Webové služby, příklad implementace (SOAP/WSDL/REST)

Webova sluzba je (podla wiki):

sluzba ponukana elektronickym zariadenim inemu elektronickemu zariadeniu, ktore spolu komunikuju cez WWW
server beziaci na vypocetnom stroji, ktory pocuva na poziadavky na specifickom porte na sieti, servuje webove dokumenty (HTML, JSON, XML, obrazky)

Webove sluzby poskytuju standard pre komunikaciu medzi roznymi SW aplikaciami, ktore mozu bezat na roznych platformach, technologiach, miestach a mozu byt pisane v uplne inych jazykoch. Vo webovych sluzbach bola technologia ako HTTP povodne navrhnuta pre komunikaciu medzi clovekom a strojom no teraz je bezne vyuzivana pre komunikaciu stroj-stroj (prenos JSON, XML).

Webove technologie prakticky obvykle predstavuju objektovo-orientovane webove rozhranie databazovemu servru, ktore vyuziva napr. iny webovy server, mobilna aplikacia.

SOAP = Simple Object Access Protocol

SOAP je aplikacny komunikacny protokol pre vymenu strukturovanych a typovanych sprav zalozenych na XML cez siet, hlavne pomocou HTTP. Ide o prvy pokus o standardizaciu webovej sluzby, existuje niekolko sablon pre komunikaciu na protokole SOAP, najznamejsou je RPC, kde su dvaja ucastnici - klient, server - a server hned odpoveda na poziadavky klienta. Je tiez vhodne pre messaging systemy ako JMS

Formy prenosu

Ako aplikacnu vrstvu pre SOAP sa da pouzit HTTP aj SMTP. Ako standard pre prenos SOAP sprav bol zvoleny XML format pre svoju rozsirenost a dostupnost vyvojovych nastrojov. Zdlhave XML ma ale aj svoje nevyhody - je sice citatelne pre cloveka ale pocitac ho zlozito parsuje.

Ukazka

Klient sa pyta webovej sluzby na informacie o produkte s productID=827635 zo skladu.

<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
   <soap:Body>
     <getProductDetails xmlns="http://warehouse.example.com/ws">
       <productID>827635</productID>
     </getProductDetails>
   </soap:Body>
 </soap:Envelope>

Odpoved webovej sluzby pre klienta

 <soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
   <soap:Body>
     <getProductDetailsResponse xmlns="http://warehouse.example.com/ws">
       <getProductDetailsResult>
         <productName>Čokoláda, sada 3 chutí</productName>
         <productID>827635</productID>
         <description>Čokoláda hořká, bílá a smetanová</description>
         <price>98,50</price>
         <inStock>ano</inStock>
       </getProductDetailsResult>
     </getProductDetailsResponse>
   </soap:Body>
 </soap:Envelope>

SOAP struktura

SOAP sprava sa sklada z:

Envelope element = obalka, ktora identifikuje XML dokument ako SOAP spravu
- obsahuje 2 child elements - Header a Body
- specifikuje
  - namespaces - vyzadovane na identifikovanie XML ako SOAP spravy
  - encoding rules - optional
- musi byt pritomny
Header element = hlavicka, ktora obsahuje hlavickove informacie
- moze rozsirovat spravu
  - o elementy z inych namespacov
  - o XML
  - moze definovat "encodingStyle"
  - moze definovat "role" atribut - For example, http://example.com/Log might designate the role of a node which performs logging. Header blocks that are processed by this node specify env:role="http://example.com/Log" (where the namespace prefix env is associated with the SOAP namespace name of http://www.w3.org/2003/05/soap-envelope).
  - moze obsahovat "mustUnderstand" atribut (znamena ze prijemca musi spracovat header)
- optional
Body element obsahujuci XML message payload
- format nie je specifikovany SOAPom, prijmatel musi vediet co ma robit so spravou
- musi byt pritomny
Fault element reportujuci errory a status

WSDL = Web Services Description Language

Je XML-based popisovaci jazyk pouzivany na popisovanie funkcionality ponukanej webovou sluzbou. Poskytuje formalnu definiciu enpointov sluzby, format poziadavkov pre invokaciu a odpovede. Umoznuje automaticky generovat obsah (klientsky kod pre pristup ku sluzbe) na zaklade WSDL popisu.

Priklad

<?xml version="1.0" encoding="UTF-8"?>
<description xmlns="http://www.w3.org/ns/wsdl" 
             xmlns:tns="http://www.tmsws.com/wsdl20sample" 
             xmlns:whttp="http://schemas.xmlsoap.org/wsdl/http/"
             xmlns:wsoap="http://schemas.xmlsoap.org/wsdl/soap/"
             targetNamespace="http://www.tmsws.com/wsdl20sample">

<documentation>
    This is a sample WSDL 2.0 document. 
</documentation>

<!-- Abstract type -->
   <types>
      <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
                xmlns="http://www.tmsws.com/wsdl20sample"
                targetNamespace="http://www.example.com/wsdl20sample">
                 
         <xs:element name="request"> ... </xs:element>
         <xs:element name="response"> ... </xs:element>
      </xs:schema>
   </types>

<!-- Abstract interfaces -->
   <interface name="Interface1">
      <fault name="Error1" element="tns:response"/>
      <operation name="Get" pattern="http://www.w3.org/ns/wsdl/in-out">
         <input messageLabel="In" element="tns:request"/>
         <output messageLabel="Out" element="tns:response"/>
      </operation>
   </interface>

<!-- Concrete Binding Over HTTP -->
   <binding name="HttpBinding" interface="tns:Interface1" 
            type="http://www.w3.org/ns/wsdl/http">
      <operation ref="tns:Get" whttp:method="GET"/>
   </binding>
   
<!-- Concrete Binding with SOAP-->
   <binding name="SoapBinding" interface="tns:Interface1" 
            type="http://www.w3.org/ns/wsdl/soap" 
            wsoap:protocol="http://www.w3.org/2003/05/soap/bindings/HTTP/"
            wsoap:mepDefault="http://www.w3.org/2003/05/soap/mep/request-response">
      <operation ref="tns:Get" />
   </binding>

<!-- Web Service offering endpoints for both bindings-->
   <service name="Service1" interface="tns:Interface1">
      <endpoint name="HttpEndpoint" 
                binding="tns:HttpBinding" 
                address="http://www.example.com/rest/"/>
      <endpoint name="SoapEndpoint" 
                binding="tns:SoapBinding" 
                address="http://www.example.com/soap/"/>
   </service>
</description>

Struktura

WSDL ma 4 najdolezitejsie elementy:

<types> definujuce datove typy pouzivane webovou sluzbou
<message> definuje datove elementy pre kazdu operaciu
<portType> popisuje operacie, ktore mozu byt vykonane a spravy, ktore suvisia s danymi operaciami
<binding> definuje protokol a datovy format pre kazdy portType

REST = Representational State Transfer

Je to architektonicky styl, alternativa k SOAP. REST je na rozdiel od SOAP zamerany na data a je postaveny na zakladoch HTTP protokolu. REST nie je standard, nema ziadnu W3C specifikaciu

Zakladne principy RESTu

stav aplikacie a chovanie je vyjadrene tzv. resourcom; kazdy resource musi mat unikatny identifikator (URL)
stav aplikacie je urceny pomocou URL, dalsie mozne stavy mozme ziskat pomocou odkazov, ktore klient dostane v odpovedi od servru; pristup na inu URL privedie aplikaciu do ineho stavu
je definovany jednotnym pristupom pre manipulaciu s resourcom v podobe 4 operacii pod skratkou CRUD - Create, Read, Update, Delete
resource moze mat rozne reprezentacie (XML, HTML, JSON, SVG, …), klient nepracuje priamo s resourcom ale s jeho reprezentaciou

Priklad

Open the following link in your browser to request a random programming joke: https://official-joke-api.appspot.com/jokes/programming/random

This is a public API implemented as RESTful web service (it follows REST conventions). Your browser will show an awful JSON-formatted programming joke, such as:

[{"id":16,"type":"programming","setup":"What's the object-oriented way to become wealthy?","punchline":"Inheritance"}]

🤦🏽‍♀️😂

You could request the same URL and get a response using any HTTP client, such as curl:

$ curl "https://official-joke-api.appspot.com/jokes/programming/random"
$ [{"id":378,"type":"programming","setup":"What's the best part about TCP jokes?","punchline":"I get to keep telling them until you get them."}]

HTTP client libraries are available in all popular languages and runtimes including Fetch in JavaScript and file_get_contents() in PHP. A JSON response is machine-readable so it can be parsed and output in HTML or any other format.

Vlastnosti

Pull-based client-server interakce - Odkazy procházené volbou klienta, založené na klasickém klient-server problému.
Stateless - Každá žádost musí být soběstačná, obsahovat všechny informace potřebné k jejímu pochopení, neopírá se o něco uloženého na serveru
Cacheable nebo non-cacheable - Schopnost ukládat odpovědi na časté požadavky
Jednotné rozhraní - Zdroje jsou přístupné prostřednictvím (HTTP) GET, POST, PUT, DELETE
Pojmenované zdroje - Každý prostředek je pojmenován pomocí adresy URL
Propojené reprezentace zdrojů - URL odkazy v objektech
Vrstvená infrastruktura - Vrstvy mezi klientem a serverem. Proxy servery, brány, brány firewall atd., výkon, bezpečnost

Rozdiely REST a SOAP

SOAP
- nezávislost na jazyku, platformě a transportu
- distribuované posílání zpráv
- standardizované
- zabudované error handling
- klient a server komunikují skrz WDSL
- dlouhá zpráva
REST
- REST je na HTTP
- jednodušší pro používání, jednodušší na učení
- flexibilnější
- efektivní (menší zprávy), rychlý, blíže webovým technologiím
- přímá komunikace
- krátký JSON