Návrh, zabezpečenie a testovanie aplikačného programového rozhrania

	Slovenská technická univerzita Materiálovotechnologická fakulta so sídlom v Trnave
	Návrh, zabezpečenie a testovanie aplikačného programového rozhrania Bakalárska práca

Autor:	Matej Kriš
Pedagogický vedúci:	Ing. Juraj Ďuďák, PhD.
Študijný odbor:	Aplikovaná informatika a automatizácia v priemysle
Akademický rok	2019/2020

Obsah práce

1.	Princíp aplikačného programového rozhrania
2.	Zabezpečenie aplikačného programového rozhrania
3.	Analýza aplikácie SAPI
4.	Návrh a implementácia aplikácie SAPI

Abstrakt Práca prezentuje návrh aplikačného programového rozhrania, jeho zabezpečenie, implementáciu a následné testovanie. Výsledkom práce je zabezpečené aplikačné programové rozhranie, ktorého funkčnosť je preukázaná pomocou vytvorenej aplikačnej časti. Práca je rozdelená do štyroch kapitol. Prvá kapitola sa zaoberá opisom aplikačného programového rozhrania, princípom návrhu REST aplikačného programovacieho rozhrania, opisom HTTP metód a testovania aplikačného programové rozhrania. Druhá kapitola je venovaná základným typom zabezpečenia, ich definíciou a možnosťami implementácie. Tretia kapitola sa zaoberá analýzou navrhovanej aplikácie, dátovým modelom a požiadavkami na jej funkčnosť. Záverečná štvrtá kapitola pojednáva o použitých technológiách a opisuje návrh, implementáciu a testovanie aplikácie.

Abstract The thesis presents the design of application programming interface, its security, implementation and subsequent testing. As a result of the thesis is the secured application programming interface, which functionality is proven by the created application part. The thesis is divided into four chapters. The first chapter describes application programming interface, fundamentals of REST API design, define HTTP methods and API testing. The second chapter focuses on basic types of API security, their definition and possibility of implementation. The third chapter describes the analysis of application, data model and functionality requirements. The last fourth chapter focuses on applied technologies and describes design, implementation and testing of the application.

Úvod Za posledné desaťročia môžeme vidieť ako Internet a informačné technológie pretvorili našu spoločnosť. Internet sa stal primárnym zdrojom vyhľadávania nových informácií a rôzne aplikácie uľahčujú každodenné pracovné a školské činnosti.
Nároky na informačné systémy sa stále zvyšujú, a preto je potrebné, aby tieto systémy dokázali medzi sebou efektívne komunikovať a vymieňať si dáta. Vďaka tomu stále viac informačných systémov využíva aplikačné programové rozhranie.
Každý moderný informačný systém, ktorý má byť úspešný, musí okrem správnej funkcionality riešiť vo veľkej miere aj bezpečnosť. Preto firmy každoročne investujú značné finančné prostriedky do zabezpečenia svojich aplikácií. Okrem toho, za únik citlivých dát podniky dostávajú veľké finančné pokuty. Väčšina informačných systémov pre svoje správne fungovanie využíva komunikáciu pomocou Internetu s cieľom získania čo najväčšieho počtu používateľov. Z toho dôvodu je potrebné používateľov bezpečne overiť, a tak je nevyhnutné do systému implementovať určitý spôsob zabezpečenia.
Bakalárska práca bude zameraná na získanie teoretických poznatkov ohľadom návrhu, fungovania, testovania aplikačného programového rozhrania a oboznámenie sa s možnosťami jeho zabezpečenia. Praktická časť predstavu

Princíp aplikačného programového rozhrania

Termín aplikačné programové rozhranie, známy pod skratkou API (Application programing interface), môžeme definovať ako zbierku funkcií a postupov, ktoré umožňujú prístup k údajom a funkciám iných aplikácií .
Napríklad pri objednávaní leteniek cez online službu, ktorá berie informácie o letenkách z viacerých leteckých spoločností. Klient vyplní potrebné údaje, ktoré služba spracuje a pošle žiadosť (request) s údajmi na servery leteckých spoločností. Servery spracujú žiadosť, nájdu dáta, ktoré vyhovujú danej žiadosti a odošlú odpoveď (response) vo vhodnom formáte (napríklad JSON) naspäť na server služby, ktorá požadovala tieto dáta. Všetky tieto dáta server spracuje a vhodne ich zobrazí klientovi.
API podľa dostupnosti môžeme rozdeliť do troch kategórií:

1. Verejné: Sú určené pre širokú verejnosť. To znamená, že nemajú žiadne prístupové obmedzenia a sú verejne dostupné. Môžu byť rozdelené do dvoch kategórií - otvorené (dáta sú k dispozícií bez poplatku) a komerčné (používateľ platí poplatok na základe cenníku danej spoločnosti) .
2. Partnerské: Nie sú prístupné verejnosti, každý kto chce získať prístup musí mať práva alebo licenciu. Toto riešenie sa využíva najmä medzi obchodnými partnermi, ktorí spolu podpísali zmluvu. Firma ktorá ponúka službu API, umožňuje partnerom tretích strán vkladať služby alebo údaje do svojich aplikácií .
3. Interné: Sú navrhnuté pre zlepšenie riešení a služieb v rámci podniku. Podnikoví programátori môžu tieto rozhrania využívať pre zlepšenie podnikových systémov a aplikácií alebo pre vytváranie nových informačných systémov a aplikácií. Táto stratégia umožňuje spoločnosti plne kontrolovať používanie API .

Prípady použitia API
Existuje veľa rôznych druhov API a môžeme ich rozdeliť podľa toho, pre aký systém boli navrhnuté. Rozdeľujú sa do týchto kategórií :

Databázové

Sú navrhnuté tak, aby umožnili komunikáciu medzi aplikáciou a databázou. Programátori tak môžu písať dotazy pre rôzne databázy. Napríklad rozhranie databázy Drupal 7 Database API umožňuje používateľom písať zjednotené dotazy do rôznych databáz, komerčných aj open-source (napr. Oracle, MongoDB, PostgreSQL, MySQL).

API operačného systému

Určuje ako aplikácie používajú prostriedky a služby operačného systému. Každý operačný systém má svoje vlastné API: Windows API, GNU/Linux kernel a macOS API. Patria tam nízkoúrovňové knižnice, ktoré umožňujú programátorom pristupovať k základným funkciám operačného systému (napr. zatvorenie okna) a tak využívať všetky výhody týchto funkcií.

Vzdialené

Definujú komunikáciu medzi aplikáciami, ktoré sú spustené na rôznych zariadeniach. Inými slovami, aplikácia pristupuje k dátam, ktoré sú umiestnené na inom mieste ako aplikácia, ktorá dáta požaduje. Komunikácia medzi týmito aplikácia prebieha cez internet, preto je väčšina vzdialených API napísaná na základe webových štandardov.

Web API
V súčasnosti patrí medzi najviac využívané. Poskytujú strojovo a ľudsky čitateľné údaje medzi webovými systémami. Jedná sa hlavne o žiadosti z webových aplikácií a odpovedí zo serverov, architektúra klient-server využívajúca HTTP protokol. Vývojári môžu pomocou webových API rozširovať funkčnosť svojich aplikácií a stránok. Jedným z príkladov je Google Maps API, ktoré umožňuje pridanie lokalizácie na web stránku.

REST API

Termín REST (Representational state transfer) definoval a navrhol v roku 2000 Roy Fielding vo svojej dizertačnej práci . REST je architektúra rozhrania, ktorá ukladá obmedzenia využívané pri vytváraní webových služieb nazývaných RESTful webové služby (web services). Tieto služby umožňujú prístup a manipuláciu s webovými zdrojmi v textovom formáte s jasne definovanými operáciami .
Zo začiatku boli webové zdroje definované ako dokumenty alebo súbory. Avšak v dnešnej dobe zdroje môžu zahŕňať všetko, čo je možné identifikovať, pomenovať, adresovať alebo spracovať. Žiadosti sa identifikujú v jednotnom identifikátore zdroja (URI - Uniform Resource Identifier) a následne sa získava odpoveď vo vhodnom formáte a to väčšinou v XML alebo JSON. Odpoveď môže potvrdiť, že došlo k určitým zmenám alebo zobraziť dáta .
REST API slúži na získanie dát, kde požadované dáta vyhľadá, vytvorí z nich objekt a následne posiela stav tohto objektu. V tomto prípade stav objektu znamená previesť dáta do požadovaného formátu, a to buď JSON alebo XML. Komunikácia medzi tým, kto žiada dáta a REST API, je vykonávaná pomocou HTTP metód, ako môžeme vidieť na obrázku 1.1.

Obr. 1.1 Komunikácia medzi klientom a REST API pomocou HTTP metód

Obmedzenia REST API

V REST systémoch existuje šesť hlavných obmedzení, ktoré definujú ako server môže spracovať a odpovedať na požiadavky klientov. Vďaka týmto obmedzeniam systém získa nefunkčné vlastnosti ako sú výkon, jednoduchosť, modifikovateľnosť, presnosť a spoľahlivosť. Ak systém nedodržuje čo i len jedno obmedzenie, nemôžeme ho považovať za REST. Medzi tieto obmedzenia sa zaraďujú :
Jednotné rozhranie
Patrí medzi kľúčové obmedzenia a navrhuje spôsob komunikácie so serverom bez ohľadu o aké zariadenie alebo aplikáciu ide. Toto rozhranie môžeme rozdeliť do štyroch častí :

1. Založené na zdrojoch. Zdroje sú identifikované v žiadosti a server neodpovedá databázovou reprezentáciou, ale namiesto toho posiela odpoveď z niektorých formátov HTML, XML alebo JSON.
2. Manipulácia so zdrojmi cez ich reprezentácie. Ak má klient reprezentáciu zdroja vo zvolenom formáte, vrátane pripojených metadát, môže upravovať alebo mazať zdroje na serveri, ale len v prípade, že má na to práva.
3. Samopopisné správy. Každá správa obsahuje dostatočné množstvo informácií o spôsobe spracovania správy, aby server mohol ľahko analyzovať žiadosť (request).
4. Hypermedia ako zdroj stavu aplikácie. Každá odpoveď servera obsahuje text s hypertextovými odkazmi na ďalšie zdroje, ktoré sú práve k dispozícii.
   

Bezstavovosť

Server neuchováva žiadne informácie o stave z novej požiadavky, ktorú vytvoril klient. Stav si uchováva klient na svojej strane. Každá žiadosť klienta musí obsahovať potrebné informácie na vybavenie žiadosti, vrátane autentifikácie a autorizácie. Takýto princíp sa nazýva bezstavovosť (stateless).

Ukladanie do vyrovnávacej pamäte

Klient môže ukladať informácie pri komunikácií so serverom do vyrovnávacej pamäte. V odpovedi musí byť definované, či je kešovateľná (cachable) alebo nekešovateľná (non-cachable), čo zabraňuje klientom uchovávať staré dáta. Ak s údajmi vo vyrovnávacej pamäte vhodne narába, môže to viesť k zníženiu komunikácie medzi serverom a klientom, a tým sa zvýši rozšíriteľnosť a výkon .

Vrstvový systém

Klient väčšinou nemá informácie o tom, či komunikuje priamo s koncovým serverom alebo len s nejakým sprostredkovateľom. Ak je teda medzi klientom a skutočným serverom nejaký iný server, nebude to ovplyvňovať ich komunikáciu. Naopak môže to zvýšiť výkon systému tak, že sa vyrovnáva záťaž a sú k dispozícií vyrovnávacie pamäte všetkých účastníkov.

Kód na požiadanie

Toto obmedzenie nie je povinné. Väčšinou sa zdroje odosielajú v statickom formáte XML alebo JSON. Vo výnimočných prípadoch servery môžu rozšíriť funkčnosť pre klienta prenosom spustiteľného kódu ako sú skripty JavaScript, ktoré sa spúšťajú v prehliadači klienta .

Princíp návrhu REST API

Systém REST API sa navrhuje tak, aby využíval výhody existujúcich protokolov. Môže byť použitý s ktorýmkoľvek protokolom, najčastejšie sa používa HTTP protokol pre webové API. Pre vývojárov to znamená, že si nepotrebujú inštalovať knižnice alebo ďalší softvér, aby mohli využívať všetky výhody návrhu REST API. Táto flexibilita umožňuje vytvárať API, ktoré vyhovujú potrebám vývojárov aj zákazníkov . Medzi základné princípy návrhu patria:

Používanie jednoduchých koncových bodov

Keď API komunikuje s iným systémom, konečné body tejto komunikácie sa nazývajú koncové body (endpoints). Každý koncový bod slúži na lokalizovanie zdroja, ku ktorému API potrebuje získať prístup. Koncové body musia byť čo najjednoduchšie a jasne špecifikovať daný zdroj.

• /produkty – koncový bod pre všetky produkty
• /produkt/123 – koncový bod pre konkrétny produkt

Používanie podstatných mien namiesto slovies

Pre opis koncového bodu sa používajú podstatné mená. Bežnou chybou je, že v názvoch koncových bodov sa používajú slovesá, aby sa vyjadrila funkčnosť koncového bodu. Na vyjadrenie funkčnosti sa používajú metódy HTTP, ktoré jasne definujú ako sa dá s koncovým bodom narábať.

• /produkty – správne použitie
• /ziskatVsetkyProdukty – nesprávne použitie

Použitie správnej HTTP metódy

Najčastejšie sa používajú metódy GET, POST, PUT/PATCH, DELETE.

Používanie parametrov

Parametre pre získanie dát sa posielajú v identifikátore zdroja, namiesto používania funkčných identifikátorov.

• /zamestanec?pracovisko=’IT’ – správne použitie
• /ziskajVsetkychZamestnancovNaPracoviskuIT – nesprávne použitie

Hierarchické používanie zdrojov

Ak zdroj obsahuje ďalšie čiastkové zdroje, je potrebné tieto zdroje rozdeliť do podpriečinkov, aby sa mohli jednoznačne identifikovať.

• /pracovisko/IT/zamestnaneci - príklad použitia

Použitie správneho stavového kódu

Sú súčasťou HTTP odpovede servera na požiadavku používateľa. Stavový kód špecifikuje ako bola odpoveď serverom spracovaná. Pri požiadavke môže byť odpoveď kladná, záporná alebo došlo k chybe. Používateľ by mal tieto odpovede spracovať a podniknúť patričné kroky. V hlavičke odpovede sa tiež nachádza stavové hlásenie, čo reprezentuje anglický slovný popis stavového kódu. Najpoužívanejšie stavové kódy sú :

200 OK (V poriadku)

Odpoveď pre úspešnú HTTP požiadavku, ktorá by mala zahŕňať aj telo odpovede. Odpoveď závisí od použitej metódy.

• GET obsahuje entitu zodpovedajúcu požadovanému zdroju
• POST obsahuje entitu opisujúcu alebo obsahujúcu výsledok akcie
• TRACE entita obsahuje správu o prijatí od koncového servera

201 Created (Vytvorený)

Výsledkom je vytvorenie nové zdroja na základe URI. Predtým, ako server pošle túto odpoveď musí zdroj vytvoriť. Ak nie je možné zdroj vytvoriť, server by mal poslať odpoveď 202 (Prijatá) .

202 Accepted (Prijatá)

Využíva sa hlavne pre akcie, ktoré potrebujú dlhšiu dobu na spracovanie. Odpoveď ukazuje, že žiadosť bola spracovaná, ale ešte nebola dokončená. Umožňuje prijať a odpovedať na požiadavku v okamihu, keď je server zaneprázdnený .

204 No content (Bez obsahu)

Server úspešne spracoval požiadavku, ale nevracia žiadny obsah. Kód sa väčšinou používa ako odpoveď pre metódy PUT, POST alebo DELETE, keď API odmietne poslať späť akúkoľvek správu. Môže sa využiť aj pri metóde GET pre oznámenie, že zdroj existuje, ale nemá žiadne dáta, ktoré by mohli byť poslané v odpovedi .

304 Not modified (Nezmenené)

Indikuje, že od poslednej žiadosti sa zdrojový dokument nezmenil a stále je uložený vo vyrovnávacej pamäti. A z toho dôvodu nie je potrebné tie isté dáta posielať znovu. Telo tejto odpovede musí byť prázdne .

400 Bad Request (Nesprávna žiadosť)

Daná požiadavka nemôže byť spracovaná, pretože obsahuje syntaktické chyby, zle parametre alebo nesprávne smerovanie žiadosti. Klient by nemal opakovať žiadosť bez opravenia chýb .

401 Unauthorized (Neoprávnený)

Klient sa snaží dostať k zabezpečeným dátam bez toho, aby sa správne autorizoval. Kód môže nastať v situácií, keď sú zadané nesprávne overovacie údaje alebo žiadne. Ak žiadosť obsahuje overovacie údaje, odpoveď poukazuje, že zadané údaje sú nesprávne .

403 Forbidden (Prístup zakázaný)

Poukazuje nato, že klient sformoval žiadosť správne a autorizácia prebehla v poriadku, ale klient nemá povolené pristupovať k zdroju. Môže ísť napríklad o priečinok, ku ktorému má prístup len administrátor .

404 Not Found (Nenájdené)

Požadovaný dokument nebolo možné nájsť, ale v budúcnosti môže byť dostupný. Tento stavový kód sa používa v prípade, ak z bezpečnostných dôvodov server nechce sprístupniť skutočný dôvod, prečo bola žiadosť zamietnutá. Ak je zdroj natrvalo odstránený, server by mal použiť kód 410 (Nedostupný).

410 Gone (Nedostupný)

Požadovaný zdroj už nie je dostupný. Používa sa v prípadoch, ak bol zdroj nastálo odstránený alebo premiestnený na iný server a daný server nemá na neho dosah .

500 Internal Server Error (Vnútorná chyba servera)

Všeobecné chybové hlásenie. Pri spracovávaní požiadavky došlo k bližšie nešpecifikovanej chybe. Táto chyba nikdy nie je spôsobená klientom, preto je vhodné žiadosť opakovať pre získanie inej odpovede .

502 Bad Gateway (Čas brány vypršal)

Túto správu dostane klient od proxy servera v prípade, ak nedostal od cieľového servera odpoveď v požadovanom čase .

Rozdelenie verzií

Patrí medzi najdôležitejšie pri návrhu API. Rozdelenie verzií zaisťuje spätnú kompatibilitu softvéru a zároveň pridáva alebo aktualizuje existujúce funkcie. Napr. pri novej aktualizácií zostáva samostatne spustená aj stará verzia systému a zároveň aj nová .

• /v1/zamestanec – stará verzia systému
  
• /v2/zamestnanec – nová verzia systému
  

Používanie filtrovania, stránkovania a zoradenia

Nie je vhodné vytvárať ďalšie zdroje, ktoré sa dajú získať pomocou filtrovania, stránkovania alebo zoradenia. Pri filtrovaní sa parametre definujú v identifikátore. V odpovedi sa posielajú len dáta, ktoré vyhovujú filtrovaniu. Stránkovanie slúži na získanie konkrétneho počtu dát. Dáta je možné zoradiť vzostupne (ASC) alebo zostupne (DESC).

• /zamestnanec?pracovisko=’IT’,date=’dd-mm-yy’ - príklad filtrovania, vypíše zamestnancov na pracovisku IT a dátum
• /zamestanec?limit=10 - príklad stránkovania, vypíše 10 zamestnancov
• /zamestnanec?sort=desc - príklad zoradenia, zoradí všetkých zamestnancov zostupne

Podporovaný formát

Vhodný formát sa vyberá na základe používateľov, ktorí budú s API pracovať, poprípade na základe systémov, ktoré sa využívajú pre správnu funkčnosť. Najčastejšie sa používa JSON formát alebo XML.

Správne chybové správy

Ak sa pri žiadosti alebo odpovedi vyskytne chyba, žiadosť/odpoveď končí chybovým kódom. Je vhodné okrem chybových kódov používať aj chybové správy, ktoré môžu bližšie ozrejmiť aký problém nastal.

Používanie štandardu

Na definovanie a implementáciu API je vhodnejšie používať štandard Open API. Tento štandard slúži na návrh RESTful API s podporou komunikačných, autentifikačných a autorizačných mechanizmov.

HTTP metódy

Hypertextový prenosový protokol (HTTP - Hypertext Transfer Protocol) je protokol, ktorý slúži na prenos dát medzi webovými servermi. Definuje množinu metód, ktoré slúžia na vyvolanie požadovanej akcie, ktorá sa má vykonať pre vybraný zdroj. Hoci má každá metóda iné využitie, môžeme nájsť niektoré ich spoločné vlastnosti . Medzi tieto vlastnosti môžeme zaradiť:

1. Žiadosť má telo
   

Medzi klientom a serverom je možné vymieňať dáta pomocou takzvaných HTTP správ. Rozlišujeme dva typy správ, a to žiadosť (request) a odpoveď (response). Žiadosti posiela klient, aby vyvolal akciu na serveri a odpovede sú reakcia servera na žiadosti od klienta. HTTP správy môžu obsahovať telo (body). Používa sa na prenášanie dát a nie v každej HTTP metóde je povinné .

1. Úspešná odpoveď má telo
   

Ak server úspešne príjme žiadosť, odpovedá HTTP správou. Tak ako pri žiadostiach, ani správa odpovede nemusí mať vždy telo. Telo odpovede tiež môže obsahovať dáta, ktoré sa odvíjajú od danej žiadosti .

1. Nevykonanie zmeny
   

Pre nevykonanie zmeny na zdroji, z ktorého sa berú dáta, sa v anglickom jazyku používa slovo idempotent. Metóda je idempotentná, ak sa dá rovnaká požiadavka vytvoriť raz alebo viackrát za sebou bez toho, aby sa vykonala nejaká zmena na serveri. To znamená, že server nezmení svoj stav alebo zmení len hodnoty požadovaných dát, poprípade nezmení žiadne dáta. Napríklad ak vykonám viackrát za sebou žiadosť pomocou metódy GET, server vždy len odpovie na danú žiadosť, ale nikdy sa nezmenia alebo neupravia dáta .

1. Bezpečnosť
   

Metóda sa pokladá za bezpečnú, ak nezmení stav servera. Inými slovami, ak vedie len k operácií na čítanie. Aj keď sa bezpečné metódy používajú len na čítanie, server môže zmeniť svoj stav tým, že si vedie štatistiky. Dôležité je, že volaním bezpečnej metódy klient nevyžaduje žiadnu zmenu na serveri sám, a preto sa server zbytočne nezaťažuje .

1. Ukladanie do vyrovnávacej pamäte
   

Nazývané tiež kešovanie (cacheable). Sú to HTTP odpovede, ktoré je možné uložiť do vyrovnávacej pamäte, aby bolo možné tieto odpovede neskôr opäť použiť. Zvyšuje sa tak rýchlosť odpovede a znižuje zaťaženie servera. Do vyrovnávacej pamäte by sa nemali ukladať citlivé dáta .

1. Povolené v HTML formulároch
   

Formuláre sú komponenty web stránky, ktoré slúžia na interakciu s používateľom. Používateľ vypíše do formuláru dáta, ktoré sa posielajú na server pre ďalšie spracovanie . Vo formulároch sa využívajú metódy GET a POST, ako môžeme vidieť v tabuľkách [metody1] a [metody2].

Základné metódy protokolu HTTP majú rôzne využitie a je vždy potrebné použiť vhodnú metódu podľa jej definície. HTTP metódy sa rozdeľujú na:

Metóda GET

Žiadosť pomocou metódy GET vyžaduje dáta, ale v žiadnom prípade ich neupravuje. Metóda sa považuje za bezpečnú, pretože sa využíva na čítanie dát. Ak sa vytvorí viacej identických žiadostí, odpoveď musí končiť vždy s rovnakým výsledkom. Žiadosť sa musí využívať len pre získavanie alebo čítanie dát .

Metóda HEAD

Táto metóda v žiadosti požaduje iba hlavičku (head) daného zdroja. Využíva sa najmä pred použitím metódy GET, aby sa zbytočne nesťahovali veľké súbory a nezaťažovala tak sieť. Odpoveď pre túto metódu by nemala obsahovať žiadne telo. Ak telo obsahuje, odpoveď sa musí ignorovať. Patrí medzi bezpečné metódy, pretože dáta neupravuje .

Metóda POST

Používa sa pre vytváranie nových dát a odosiela dáta na server. Parametre tejto metódy sa ukladajú v tele (body) a nemajú maximálnu dĺžku. Zvyčajne sa odosiela prostredníctvom HTML formulára a vykoná zmenu dát na serveri. Patrí medzi nebezpečné metódy a po opakovanom volaní identických žiadostí vždy vytvára nové dátové záznamy .

Metóda PUT

Vytvára zmenu alebo aktualizuje dáta na serveri. Na rozdiel od POST metódy je možné PUT metódu viackrát použiť bez toho, aby vykonala ďalšie zmeny na serveri. Ak po využití metódy PUT aktualizujem dáta a znova použijem túto metódu s tými istými parametrami, nepríde k žiadnej zmene, pretože dáta sa už zmenili v predošlej žiadosti. Tým, že vytvára dátovú zmenu pokladá sa za nebezpečnú metódu .

Metóda DELETE

Ako už napovedá názov vymaž (delete) sa používa na vymazanie dát z určitého zdroja. Metóda sa môže používať viackrát po sebe bez toho, aby sa vykonali ďalšie zmeny v zdrojovom úložisku . Po poslaní metódy DELETE pre vymazanie dát na základe určitého identifikátora sa dáta vymažú. Avšak, ak sa pošle žiadosť s rovnakými údajmi znova, nevykoná sa žiadna zmena. Dáta boli odstránené v prvej žiadosti.

Metóda CONNECT

Začína obojsmernú komunikáciu s požadovaným serverom. Môže sa použiť pre otvorenie TCP tunela. Využíva sa v situácií, keď klient odošle žiadosť o vytvorenie TCP tunela k určitému miestu . Žiadosť sa odosiela na proxy server, ktorý vytvára spojenie v mene klienta. Ak je spojenie úspešné, proxy server pokračuje v udržiavaní tohto spojenia .

Metóda OPTIONS

Pomocou metódy OPTIONS je možné získať informácie o možnostiach komunikácie, ktoré sú dostupné na zadanej adrese. Ďalej metóda umožňuje klientovi zistiť možnosti daného servera bez toho, aby sa vyvolalo načítanie dát. Za možnosti servera sa pokladajú HTTP metódy, ktoré podporuje. Používa sa na kontrolu funkčnosti web servera alebo pre testovanie API .

Metóda TRACE

Metóda sa používa na vyvolanie vzdialenej spätnej väzby, čím poskytuje užitočný mechanizmus testovania. Konečný príjemca by mal odoslať správu, že žiadosť prijal, a to ako odpoveď so stavovým kódom 200 (V poriadku) .

Metóda PATCH

Používa sa na čiastočnú zmenu dát na serveri. Metóda by sa nemala používať viackrát po sebe s tými istými údajmi, hoci existujú spôsoby ako takúto žiadosť poslať viackrát po sebe bez toho, aby sa vykonali ďalšie dátové zmeny . Napríklad pri zmene mena používateľa sa v žiadosti posiela len zmenené meno. Ak by sa použila PUT metóda museli by sa posielať všetky údaje používateľa.

Vlastnosti metód:Jednotlivé HTTP metódy majú rôzne využitie, ale niektoré vlastnosti majú spoločné. Bližšiu špecifikáciu spoločných vlastností je možné vidieť v tabuľkách [metody1] a [metody2].

Tabuľka 1.1: Vlastnosti metód GET, HEAD, POST, PUT a DELETE [12]

Vlastnosti metód GET, HEAD, POST, PUT a DELETE

Vlastnosť/Metóda	GET	HEAD	POST	PUT	DELETE
Žiadosť má telo	Nie	Nie	Áno	Áno	Môže
Úspešná odpoveď má telo	Áno	Nie	Áno	Nie	Môže
Bezpečná	Áno	Áno	Nie	Nie	Nie
Idempotent	Áno	Áno	Nie	Áno	Áno
Cacheable	Áno	Áno	Áno	Nie	Nie
Povolené v HTTP formulároch	Áno	Nie	Áno	Nie	Nie

Tabuľka 1.2: Vlastnosti metód CONNECT, OPTIONS, TRACE a PATCH [12]

Vlastnosti metód CONNECT, OPTIONS, TRACE a PATCH

Vlastnosť/Metóda	CONNECT	OPTIONS	TRACE	PATCH
Žiadosť má telo	Nie	Nie	Nie	Áno
Úspešná odpoveď má telo	Áno	Áno	Nie	Áno
Bezpečná	Nie	Áno	Nie	Nie
Idempotent	Nie	Áno	Áno	Nie
Cacheable	Nie	Nie	Nie	Nie
Povolené v HTTP formulároch	Nie	Nie	Nie	Nie

Testovanie REST API

REST aplikačné programové rozhranie (REST API) slúži na prepojenie jednotlivých vrstiev aplikácie. Aplikácia obyčajne obsahuje tri vrstvy: dátovú vrstvu, vrstvu služieb (REST API) a aplikačnú vrstvu (používateľské rozhranie). Vrstva REST API obsahuje pravidlá, ako môžu používatelia interagovať so službami, údajmi alebo funkciami aplikácie. Vrstva služieb komunikuje s dátovou vrstvou a aj s prezentačnou vrstvou, predstavuje najvhodnejšie miesto pre nepretržité testovanie. Aj keď existuje veľa aspektov testovania, vo všeobecnosti testovanie slúži na vytvorenie žiadosti (request) na jeden alebo viac koncových bodov (endpoints) a overenie odpovedi (response). Pri odpovedi sa kontroluje výkon, bezpečnosť, správne fungovanie funkcií alebo iba kontrola stavu .
Rozdelenie a výhody testovania
Štandardne sa testovanie rozdeľuje na 3 typy: black box (nie je nutné poznať štruktúru kódu aplikácie), grey box (je potrebná čiastočná znalosť kódu aplikácie) a white box (je nutná znalosť štruktúry kódu aplikácie). Testovanie REST API sa zaraďuje do black box testovania a kladie dôraz na testovanie logiky aplikácie, dátových odpovedí, bezpečnosti a prekážok vo výkone. Medzi výhody testovania sa zaraďuje :

• Skoršie testovanie: pri komplexných aplikáciach nie je potrebné čakať na dokončenie celej aplikácie. Po vytvorení logiky REST API sa môžu vytvoriť testy na overenie správnosti odpovedí a údajov .
• Jazyková nezávislosť: dáta aplikácie sa posielajú vo formáte XML alebo JSON, takže ľubovoľný programovací jazyk môže byť použitý na testovanie, nezávisle na programovacom jazyku ktorým bola vyvíjaná aplikácia .
• Nezávislosť na grafickom rozhraní: pri testovaní nie je potrebné grafické rozhranie, ktoré nahrádzajú aplikácie určené na testovanie .
• Rýchle hľadanie chýb: ak test zlyhá, je možné presne určiť, kde sa v systéme nachádza chyba .
• Rýchlosť a rozsah testovania: testovania REST API je oveľa rýchlejšie v porovnaní s testovaním používateľského rozhrania. To znamená, že chyby sú nájdené oveľa skôr a zároveň môžu byť hneď opravené .
• Zlepšené pokrytie: väčšina rozhraní má funkcie, ktoré umožňujú vytvárať automatické testy s vysokým pokrytím, vrátane funkčného testovania a nefunkčného testovania .
  

Testovanie predstavuje komplexný proces, pri ktorom je možné testovať rôzne prvky rozhrania. Z toho dôvodu sa testovanie rozdeľuje na rôzne kategórie podľa účelu, a to na:
Testovanie funkčnosti
Pri tomto type testovania sa overuje funkčnosť REST API na základe stanovených požiadaviek alebo špecifikácie. Úlohou funkčného testovania je overenie každej funkcie rozhrania, poskytnutím správnych vstupov a overenie výstupu na základe funkčných požiadaviek. Využíva sa hlavne black box testovanie, to znamená bez skúmania štruktúry kódu. Testy sú vykonávané manuálne alebo sú automatizované. Testovanie funkčnosti zvyčajne obsahuje tieto kroky :

1. Identifikácia funkcie, ktorá sa od softvéru očakáva
2. Vytvorenie vstupov na základe špecifikácie funkcie
3. Určenie výstupov na základe špecifikácie funkcie
4. Vytvorenie a spustenie testu
5. Porovnanie výsledku s očakávaným výsledkom

Testovanie spoľahlivosti
Testuje sa, či môže byť vytvorené nepretržité spojenie s konzistentnými výsledkami. Testovanie spoľahlivosti sa vykonáva, aby sa zabezpečilo, že systém REST API je spoľahlivý, spĺňa účel na ktorý bol vytvorený po stanovenú dobu v danom prostredí a je schopný vykonávať bezporuchovú prevádzku. Medzi typy testovania spoľahlivosti sa radia :

• Testovanie funkcií: kontrolujú sa jednotlivé funkcie REST API a ich spoľahlivosť v nasledujúcich krokoch: každá funkcia REST API je spustená aspoň raz, interakcia medzi funkciami je čo najmenšia a každá funkcia musí byť skontrolovaná, či sa vykonáva správne.
• Záťažové testovanie: REST API zvyčajne funguje lepšie na začiatku procesu a potom začne degradovať. Záťažové testovanie testuje správanie a výkonnosť REST API pod maximálnou záťažou.
• Regresné testovanie: využíva sa hlavne na kontrolu toho, či nevznikli nové chyby na základe opravy predošlých chýb alebo po pridaní nových funkcií. Vykonáva sa po každej zmene alebo aktualizovaní REST API.

Bezpečnostné testovanie
Využíva sa na odhalenie zraniteľných miest, hrozieb a rizík, ktoré mohli vzniknúť pri programovaní REST API a zabraňuje útokom zo strany hackerov. Účelom bezpečnostného testovania je identifikovať slabo zabezpečené miesta REST API, z ktorých by mohlo prísť k úniku informácií. Kontrolujú sa definované bezpečnostné požiadavky vrátane overovania, oprávnení a riadeného prístupu .