REST API – Úvod I. DÍL

Všude se o RESTu mluví, jak v rámci architektury nebo pracovních nabídek. Mrkněte se na jobs, skoro u každé pozice programátora se vyžaduje znalost RESTu. Dokonce je to běžné i u frontend vývojářů. Opravdu ale všichni vědí, co to ten REST je? Co si pod tím můžete představit? Existují nějaký standardy nebo best practice? Jak se říká, sedm krát měř a jednou řež. Musím říct, že spoustu borců si to vyložilo po svém. Říkám to podle vlastní zkušenosti, co jsem viděl a co jsem zažil. V rámci sady článku REST API Vám budu snažit předat mnou nabité znalosti a zkušenosti.

Začneme úplným základem. Co vlastně zkratka REST znamená? REST je Representational State Transfer doslova reprezentační stavový přenos. Jedná se o architektonické rozhraní. Jeho autorem je Roy Fielding. Vytvořil ho v roce 2000 v jeho disertační práci. Někdy uvidíte také pojem RESTful. Aby vaše api mohlo dostat toto označení musíte splňovat šest omezení, o kterých se dočtete dále.

1. Client server

Pod pojmem “client” si můžete představit webový prohlížeč (Chrome, Safari, FireFox). Server je v podstatě počítač, které poskytuje určité služby. Toto omezení říká, že sever nemá vědět, co se děje na clientovi. Například kliknete na slider nebo rozjížděcí menu. Na clientovi můžete modifikovat data, která zobrazujete, například v e-shopu. Server o tom nemá vědět. Každý plní svoje povinnosti a nestará se o práci toho druhého.

2. Stateless

Znamená bez stavový. Všechny informace musí být obsažené v příchozím requestu. Žádné cookies ani podobné radosti. K autentifikaci a autorizaci se používá token. Autentifikace obsahuje slovo ten, neboli to může dělat ten daný uživatel. Autorizace, obsahuje slovo to, neboť daný uživatel na to má právo (například vykonat danou akci). Pokud budete chtít článek o tokenech a autorizaci pište mi na twitteru @jurij_starynec

3. Cache-able

Jednoduše řečeno musíte klientovi umožnit requesty cachovat. Znamená to, že požadavek nejde ke zpracování na server, ale vrátí se výsledek z mezipaměti. Cache snižuje latenci, zatížení serverů, selhaní sítě a nakonec bandwidth. Všechny requesty GET v základu by se měli cachovat, pokud nenastane zvláštní stav. POST requesty by se v základu neměli cachovat. Pokud request bude obsahovat hlavičky Expires nebo Cache-Control, tak by se cachovat mělo. PUT a DELETE v žádnem případě.

Na další tři omezení se můžete těšit v dalším díle. Abyste článek nezmeškali, sledujte mě na twitteru. Sledujte další díl.