REST API – Úvod II. DÍL

Zbývají nám další tři omezení, které probereme v tomto článku. Pokud jste zmeškali první článek, začněte u něj.

4. Uniform interface

V překladu to znamená jednotné rozhraní. Toto omezení rozděluji implementaci od architektury. Je to podobné jako v programovacích jazycích. Nadefinujete si interface s funkcí, která má jasný vstup a výstup. Je Vám jedno, jak developer naimplementuje interface, pro Vás je důležité, že se můžete spolehnout na výstup. Podobně funguje i rest api. Neřešíte, jak data jsou uložena na serveru, důležité je, jak jsou Vám interpretovaná. Client v requestu si může říct, zdá-li chce HTML, JSON nebo XML a to dostane.

Uniform interface přináší jednoduché použití. Pokud každý by dodržoval pravidla RESTu (bohužel svět není ideální), tak vy jako programátor je můžete jednoduše implementovat. Pokud budete chtít například smazat libovolný prvek, tak můžete pomoci URI a HTTP metody. Na většině api by to mělo být podobné až stejné. Nemusíte tak každou implementaci api složitě číst a studovat dlouhé dokumentace a přemýšlet, co tím básník myslel.

Každý request a response, který proběhne mezi klientem a serverem by měl být nezávislý. To znamená, že první request by neměl mít vliv na request následující a opačně.

S dalším prvkem jsem se setkal velmi málo. Většinou na to není dostačující budget, programátoři jsou líní hova*a nebo se říká, že to je zbytečná funkce. Bavím se o HATEOAS. IMHO si myslím, že toto je základ a implementátorům api dokáže ušetřit dost práce a času. Obecná teorie praví, že v REST api můžete “listovat” jako na webové stránce. Neboli od posledního prvků jste schopný se dostat k prvnímu. Jsou to tak zvané linky, v responsu jsou označované jako _link. Například založíte na api novou knihu a v odpovědi dostanete objekt, který se vytvořil a (link) url adresu na něj. Nebo pošlete request na vylistování knih, v response dostanete data (jednotlivé položky). V první řadě by tam mělo být stránkováni, link na první a poslední prvek a další. O tom povím více v dalším díle.

5. Code on demand (optional)

Toto omezení je volitelné a v překladu říká kód na vyžádání. Nejlépe se to pochopí na příkladu. Stáhnete si obsah stránky do clienta (prohlížeče) a budete chtít spustit super truper kalkulačku, která ještě v prohlížeči není. Provoláte api a stáhnete si rozšiření v podobě snippetu nebo skriptu, který si budete moci v prohlížeči spustit.

6. Layered system

V překladu vrstvený systém. Toto omezení nám říká jak správně by měl vypadat vrstvený systém nebo architektura. Celková myšlenka je, že business logika, data a prezentace dat, by měla být oddělená. Představte si, že máte jeden endpoint, který si můžete vrátit jako JSON nebo XML. Pokud data a reprezentaci byste měli spojenou, tak při změně dat byste museli dělat opravu na dvou místech.

Tak to máme za sebou teorii. V dalších dílech se můžete těšit na praktické ukázky. Jak strukturovat api, množné nebo jednotné číslo enpointu, hlavičky, metody, sorting a mnoho dalšího. Pokud se Vám článek líbil sledujte mě na twitteru, aby Vám neunikl další díl.