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

Obsah

1
- 1.1 Použité technológie
- 1.2 Implementácia aplikácie SAPI
2 Záver
3 Zoznam použitej literatúry

Pre návrh a následnú implementáciu aplikácie SAPI boli využité rôzne technológie, ktoré sú samostatne rozdelené pre návrh a tvorbu API, aplikačnú časť a testovanie. Technológie boli vybrané tak, aby uľahčovali jednotlivé kroky tvorby a zároveň spĺňali určitý štandard, ktorým sú moderné aplikácie v dnešnej dobe vyvíjané.

Použité technológie

Návrh a tvorba API

Swagger editor: Swagger je program s otvoreným zdrojovým kódom, ktorý pomáha programátorom navrhnúť, zostaviť, dokumentovať a používať webové služby REST API. Formát, ktorý sa vytvorí v swaggeri je ľahko čitateľný strojovo a aj človekom. Swagger využíva špecifikáciu OpenAPI.
OpenAPI: Definuje štandard pre REST API, ktorý umožňuje človeku a počítaču pochopiť možnosti služby bez prístupu k zdrojovému kódu, dokumentácii alebo prostredníctvom kontroly sieťovej prevádzky. Ak je štandard správne aplikovaný, používateľ môže porozumieť a komunikovať so vzdialenou službou s minimálnym množstvom implementačnej logiky.
Node.js: Multiplatformové programové prostredie, ktoré rozširuje programovací jazyk JavaScirpt a umožňuje jeho využitie aj mimo internetového prehliadača, a to aj na strane servera. Aplikácia v Node.js sa spúšťa v jednom procese bez toho, aby sa pre každú požiadavku vytvorilo nové vlákno. Ak je potrebné vytvoriť vstupno-výstupnú operáciu, ako získanie dáta z databázy, namiesto blokovania vlákna a zbytočného čakania na cykly CPU, Node.js obnoví operácie, keď sa vráti odpoveď. To umožňuje zvládnuť tisíce súčasných pripojení k jednému serveru bez toho, aby sa zaťažil procesor.
Express: Flexibilný webový framework pre Node.js, ktorý poskytuje množstvo funkcií pre webové a mobilné aplikácie. Vďaka veľkému počtu metód HTTP a middleware, ktoré sú k dispozícii, je možné jednoducho a rýchlo vytvárať spoľahlivé a výkonné API.
MySQL: Pre ukladanie dát v databáze sa využíval SQL relačný databázový server MySQL, kde každá databáza je tvorená z viacerých tabuliek, ktoré obsahujú riadky a stĺpce. V riadkoch sú uložené záznamy databázy a stĺpce udávajú dátový typ.

Aplikačná časť

HTML: Hypertextový značkovací jazyk (HyperText Markup Language) je základný stavebný blok pre vytváranie webový stránok. Webový prehliadač obdrží HTML dokumenty od webového serveru alebo z lokálneho úložiska a renderuje dokumenty na multimediálne webové stránky. HTML popisuje sémanticky štruktúru webovej stránky. Využíva sa spolu s technológiou ako kaskádové štýly (Cascading Style Sheets CSS - vzhľad stránky) a skriptovacími jazykmi (JavaScript - funkcionalita stránky).
Bootstrap: Patrí k najpoužívanejším CSS knižniciam a využíva sa na programovanie responzívnych web aplikácií. Má predpripravené a upravené jednotlivé komponenty, ktoré je možné jednoducho implementovať a upravovať vo svojom projekte.
Angular: Platforma pre vývoj aplikácií a vytváranie efektívnych a sofistikovaných jednostránkových aplikácií (single-page apps). Zameriava sa na zjednodušenie vývoja a aj testovanie aplikácie. Využíva programovací jazyk TypeScript (JavaScript s využitím voliteľného statického písania) vytvorený firmou Microsoft.
Okta: Spoločnosť, ktorá poskytuje online riešenia pre zabezpečenie a autentifikáciu moderných aplikácií a integráciu ovládačov identity do aplikácii a webových služieb pre vývojárov. V aplikácií sa bude využívať pre OAuth 2.0 server.

Testovanie

Postman: Platforma Postman slúži pre vytváranie API. Funkcie, ktoré obsahuje urýchľujú každý jeden krok pri vytváraní. Umožňuje vytvorenie žiadosti pre získanie dát z API. Jednou z jeho funkcií je, že umožňuje vytvárať testy pre kontrolu funkcionality API.
Testmace: Program, ktorý slúži na vytváranie žiadostí na API s využitím rôznych premenných a možnosťami autentifikácie. Umožňuje písanie testov pomocou grafického editora a vytváranie automatických testov.
JavaScript: Skriptovací interpretovaný programovací jazyk využívaný hlavne pre tvorbu web stránok, ale je možné ho použiť aj na strane servera a vytváranie testov. Testovacie skripty s využitím Postman aplikácie sú písane v JavaScripte. Vytvorené testy kontrolujú funkcionalitu a spoľahlivosť API.

Implementácia aplikácie SAPI

Aplikačné programové rozhranie

Základom pri tvorbe aplikácie bol návrh API pre senzorický systém, ktorý vyvíja vedúci bakalárskej práce. V tomto základnom návrhu bolo potrebné vyriešiť problematiku zabezpečenia prístupu do API. Ako prvé sa upravili existujúce koncové body, stavové kódy a dokumentácia návrhu API. Následne sa do návrhu pridali schémy zabezpečenia pre jednotlivé zabezpečovacie algoritmy.
Na ukážke kódu [yamlCode] je možné vidieť návrh koncového bodu /auth/application pomocou štandardu OpenApi v editore Swagger. Pri návrhu sa najprv definovalo akú HTTP metódu bude koncový bod využívať (POST). Ďalej sa napísal popis pre daný koncový bod, či žiadosť musí mať telo a aký formát použiť (JSON). Ako posledné sa definovali stavové kódy odpovede. Jednotlivé stavové kódy odkazovali k ďalším schémam, ktoré boli ďalej navrhnuté v editore.

  "/auth/application/":
    post:
      tags:
        - Auth
      summary: Save new application detail
      description: "Return application details. Only for system admin."
      requestBody:
        required: true
        content:
          application/json:
            schema:
              ref: "#/components/schemas/LoginApplication"
      responses:
        "201":
          description: Application inserted
          content:
            application/json:
              schema:
                ref: "#/components/schemas/StateResponse"
        "400":
          description: Incomplete source information
          content:
            application/json:
              schema:
                ref: "#/components/schemas/StateResponse"
        "401":
          ref: "#/components/responses/UnauthorizedError"
        "403":
          ref: "#/components/responses/PrivilegiesError"

[yamlCode]

Generovanie šablóny API
Po dokončení návrhu sa pomocou nástroja na generovanie, vygenerovala šablóna API pre framework Express na základe napísaného návrhu. Príkaz generátora je možné vidieť na ukážke kódu [genCode]. Ako prvý je príkaz pre spustenie Java aplikácie, v tomto prípade aplikácie pre generátor. Ďalej sa definuje súbor s navrhnutým API (api.yaml), server generovania (nodejs-express-server) a súbor uloženia pre generovaný kód.

 java -jar openapi-generator-cli-4.2.1.jar generate -i 
 api.yaml -g nodejs-express-server -o ./server

[genCode]

Po tomto kroku nasledovala implementácia funkcií pre zabezpečovacie algoritmy a pre koncové body (endpoints). Pri koncových bodoch sa musela riešiť komunikácia s MySQL databázou pre získanie dát, ktoré sú v nej uložené. API bolo spúšťané prostredím Node.js.
Middleware
Pre identifikáciu typu zabezpečenia sa využíval takzvaný middleware, ktorého základnú funkcionalitu má implementovaný framework Express. Funkcia middleware spočíva v tom, že každá jedna žiadosť smerovaná na API najprv prejde cez middleware. Ak je žiadosť správna, obsahuje hlavičku autorizácie so správnymi údajmi, posiela sa ďalej na API. API žiadosť spracuje a odosiela vhodnú odpoveď. Príklad fungovania middleware je zobrazený na obrázku 4.1.

Obr 4.1 Ukážka fungovania middleware

Implementovaný middleware pre zistenie typu zabezpečenia je zobrazený na ukážke kódu [expressCode]. Do premennej authStr sa najprv uloží hlavička žiadosti, následne sa zisťuje o aký typ zabezpečenia ide a volá sa príslušná metóda. Metódy sú definované v inom súbore a ako vstupné parametre sa berú žiadosť (req), odpoveď (res) a skok na ďalší koncový bod (next). Ak hlavička nie je definovaná, API vráti stavový kód 401 (Neoprávnený).

    this.app.use((req, res, next) => {
        let authStr = req.headers.authorization;
        if (typeof authStr !== 'undefined') {
            if (authStr.startsWith("Basic")) {
              return authentication.basicAuth(req, res, next);

            } else if (authStr.startsWith("Bearer")) {
              return authentication.jwtAuth(req, res, next);

            } else if (authStr.startsWith("ApiKey")) {
              return authentication.apiKeyAuth(req, res, next);

            } else if (authStr.startsWith("Oauth")) {
              return authentication.oAuth2(req, res, next);
            }
        } else {
          res.status(401).json({ message: "Unsupported Auth." });
        }     
    });

[expressCode]

Definovanie koncového bodu
Pre každý koncový bod bola podľa návrhu API vytvorená asynchrónna funkcia, ktorá mala rovnaký názov ako koncový bod, a navyše v názve pridanú HTTP metódu, ktorú používa. V bloku try, API vytvára dotaz na MySQL databázu, ktorý v prípade správne zadaných hodnôt vracia výsledok dotazu. Ak je dotaz nesprávny, API vracia chybový stavový kód. Vo výnimke catch sa zachytáva nesprávna žiadosť na koncový bod. Na ukážke kódu [expressCode2] môžeme vidieť funkciu pre HTTP metódu GET.

  static authApplicationIdGET({ id }) {
    return new Promise(
      async (resolve) => {
        try {
          let sqlString = "SELECT * FROM apps INNER JOIN servers ON 
          apps.server_id = servers.id WHERE apps.id = ?";
          authentication.pool.query(options(sqlString, id), 
          (err, result) => {
              if (err) {
                resolve(Service.rejectResponse({
                'message': "Internal server error"}));
              } else if (result.length === 0) {
                resolve(Service.rejectResponse({
                'message': "ID doesn't exist"}, 400));
              } else {
                resolve(Service.successResponse(result, 200));
              }
          }); } catch (e) {
          resolve(Service.rejectResponse(
            e.message || 'Invalid input',
            e.status || 405,
          )); } }, ); }

[expressCode2]

Aplikačná časť

Pre názornú ukážku správnosti fungovania API bola vytvorená aplikačná časť (front-end). Zámerom bolo preukázať funkcionalitu jednotlivých zabezpečovacích algoritmov, ich implementáciu a použitie zabezpečenia pri dotazoch na koncové body. Aplikačná časť je tvorená vo webovom prostredí s využitím webového frameworku Angular. Ten obsahuje funkcie pre HTTP metódy, ktorými je možné vytvárať žiadosti na API. Štruktúra webu, ako tlačidlá, formuláre a odkazy, sú písané v HTML. Vzhľad týchto elementov je tvorený triedami knižnice Boostrap.
Na ukážke kódu [angularCode] je možné vidieť Angular funkciu pre prihlásenie pomocou webového tokenu JSON. Využíva sa HTTP metóda POST, kde sa odosiela meno, heslo a telo žiadosti. API overí používateľa a vráti token. Token sa ukladá do lokálneho úložiska prehliadača a používateľ je presmerovaný na domovskú stránku.

  jwtLogin() {
    this._auth.authPost(this.jwtUsername, this.jwtPassword, this.body)
    .subscribe(
          res => {
            localStorage.setItem('token', res.token);
            this._router.navigate(['/homepage']);
          },
          err => alert("Error")
        );
  }

[angularCode]

Úvodná stránka aplikácie SAPI
Na úvodnej stránke sa demonštrujú jednotlivé metódy zabezpečenia. Používateľ si môže zvoliť, aký typ zabezpečenia použiť, ako je možné vidieť na obrázku 4.2.
Prihlásenie
Pri každom type zabezpečenia používateľ zadáva meno a heslo (prebehne jednoduchá autentifikácia). Aplikácia odosiela žiadosť na koncový bod API určený pre prihlásenie. V hlavičke žiadosti sa odosiela zašifrované meno a heslo. V tele žiadosti sa odosiela informácia, aký typ zabezpečenia si používateľ zvolil. Táto informácia je určená pre koncový bod prihlásenia. Middleware z hlavičky rozpozná, že ide o jednoduchú autentifikáciu a zavolá príslušnú funkciu. Funkcia pre jednoduchú autentifikáciu vyhľadá meno používateľa v databáze, rozšifruje heslo a porovná ho s heslom zo žiadosti. Ak sú údaje správne, API pokračuje na koncový bod prihlásenia. V prípade nesprávnych údajov, API odosiela odpoveď s chybovým hlásením. Aplikácia odpoveď spracuje a zobrazí chybové hlásenie.

Obr. 4.2 Úvodná stránka aplikácie SAPI

Odpoveď koncového bodu prihlásenia
Koncový bod pre prihlásenie si z tela žiadosti vytiahne informáciu o zvolenom type zabezpečenia používateľom a na základe toho odosiela odpoveď. Pri jednoduchej autentifikácii ako odpoveď odosiela zakódované meno a heslo. Pri webovom tokene JSON odosiela vygenerovaný token a pri API kľúči vygenerovaný API kľúč. Aplikácia tieto odpovede spracuje a údaje pre overenie uloží do lokálneho úložiska prehliadača. Pri štandarde OAuth 2.0 využíva server tretej strany (Okta), na ktorý je používateľ presmerovaný a zadáva meno a heslo. Následne po úspešnom overení server Okta vracia token, ktorý aplikácia ukladá do lokálneho úložiska. Presmerovanie na Okta server môžeme vidieť na obrázku 1.3.

Obr. 4.3 Overenie pomocou serveru Okta

Overovanie po prihlásení
Po úspešnom prihlásení každá nová žiadosť na API obsahuje hlavičku autorizácie na základe zvoleného typu zabezpečenia. V API middleware rozozná o aký typ zabezpečenia ide a zavolá príslušnú funkciu. Funkcia pre webový token JSON overuje platnosť tokenu a dešifruje ho na základe zabezpečovacieho kľúča. Funkcia pre API kľúč kontroluje, či je zadaný API kľúč pridelený používateľovi. Funkcia pre OAuth 2.0 odosiela token na overovací server Okta. Ak overenie prebehne v poriadku, žiadosť pokračuje na prislušný koncový bod. V aplikácií sa využíva koncový bod /auth/application s HTTP metódami GET, PUT, POST, DELETE a pracuje sa s tabuľkami Aplikácie (Apps) a Servery (Servers).
Domovská stránka aplikácie SAPI
Ak sa používateľ úspešne prihlási, je presmerovaný na domovskú stránku (Home). Na tejto stránke môže využiť funkciu pre vypísanie dát do tabuľky na základe zadaného ID aplikácie, prejsť na stránku Aplikácie (Apps) alebo sa odhlásiť (Logout). Po zadaní ID aplikácie a stlačení tlačidla Get, aplikácia odosiela žiadosť HTTP metódou GET na koncový bod. Vo funkcií koncového bodu pre HTTP metódu GET, API vytvára dotaz na databázu pre získanie dát z tabuľky Aplikácie (Apps) a z tabuľky Servery (Servers). Ak je ID aplikácie správne, vracia vybrané dáta späť aplikácií. Dáta do aplikácie prichádzajú asynchrónne a aplikácia ich musí spracovať a uložiť do pola. Následne aplikácia týmito dátami naplní tabuľku pre aplikáciu (App Table) a tabuľku pre server (Server Table). Na základe toho, aké zabezpečenie sa využíva, aplikácia vypíše autorizačnú hlavičku žiadosti. Na obrázku 1.4 je možné vidieť, že sa využíva zabezpečenie pomocou webového tokenu JSON.

Obr 4.4. Domovská stránka aplikácie SAPI

Stránka Aplikácie
Na stránke Aplikácie (Apps) sa zobrazuje tabuľka naplnená dátami z databázy. Dáta pochádzajú z tabuľky Aplikácie (Applications). Pri každom načítaní stránky aplikácia odosiela HTTP metódu GET pre získanie dát. Po overení API žiadosť spracuje a vytvára dotaz na databázu pre získanie všetkých dát z tabuľky. Tieto dáta odosiela v odpovedi a aplikácia ich spracuje a zobrazí v tabuľke Dáta Aplikácií (Apps Data). Zobrazovaná tabuľka je určená na ukážku fungovania dotazov na API a HTTP metód (PUT, POST, DELETE). Na stránke sa tiež zobrazí hlavička autorizácie, ktorá sa odosiela v žiadosti na API. Na obrázku 1.5 je možné vidieť žiadosť pomocou API kľúča. Používateľ má možnosť kliknúť na tlačidlo Pridaj Dáta (Add Data) pre pridanie dát alebo na tlačidlá pre zmazanie a úpravu dát.
Tlačidlo Vymaž dáta
Ak používateľ stlačí tlačidlo Vymaž (na obrázku 1.5 červené tlačidlo), zobrazí sa výstražné okno, či chce daný záznam naozaj vymazať. Po kliknutí na tlačidlo OK aplikácia odosiela na API žiadosť s HTTP metódou DELETE spolu s ID aplikácie, ktorá má byť vymazaná. API žiadosť spracuje a zo žiadosti si vyberie ID záznamu, ktorý sa má vymazať. Na databázu vytvára dotaz pre vymazanie dát na základe ID. Aplikácii odosiela odpoveď o vymazaní dát alebo o chybe pri vymazávaní. Aplikácia odpoveď spracuje, pri vymazaní dát z databázy znova načíta stránku bez vymazaného záznamu a pri chybe zobrazí chybové hlásenie.

Obr. 4.5 Zobrazenie stránky Aplikácie

Tlačidlo Uprav dáta
Po stlačení tlačidla Uprav (na obrázku 1.5 modré tlačidlo) sa zobrazí modálne okno s vyplneným formulárom, ako je zobrazené na obrázku 1.6. Používateľ tam má možnosť upraviť dáta konkrétneho záznamu. Po stlačení tlačidla Uprav Dáta (Edit Data) sa odosiela na API požiadavka cez HTTP metódu PUT spolu s upravenými dátami v tele žiadosti. Z tela žiadosti si API vyberie dáta upravené používateľom a odosiela dotaz na databázu pre úpravu dát v tabuľke. Po vykonaní dotazu, API odosiela odpoveď späť aplikácií. Ak úprava dát prebehla v poriadku, aplikácia znova načíta stránku s upravenými dátami. V prípade, že pri úprave nastala chyba, aplikácia chybu vypíše.
Tlačidlo Pridaj dáta
Po stlačení tlačidla Pridaj Dáta (Add Data) sa zobrazí modálne okno s formulárom podobne ako na obrázku 1.6 s tým rozdielom, že formulár je prázdny. Po vyplnení dát a stlačení tlačidla Pridaj Dáta (Add Data) sa posiela na API žiadosť s HTTP metódou POST spolu s vyplnenými dátami v tele žiadosti. Z tela žiadosti si API vyberie dáta zadané používateľom. Následne vytvára dotaz na databázu pre pridanie dát do tabuľky. Po vykonaní dotazu, API v odpovedi odosiela informácie o pridaní alebo chybe pri pridávaní dát do databázy. Aplikácia odpoveď spracuje a pri úspešnom pridaní dát znova načíta stránku s pridanými dátami alebo zobrazí chybu pri pridávaní.

Obr. 4.6 Modálne okno s formulárom pre úpravu dát

Tlačidlo Odhlásenie
Stlačením tlačidla Odhlásenie (Logout) sa odstránia dáta z lokálneho úložiska a používateľ je presmerovaný na domovskú stránku, kde má možnosť znova si vybrať prihlásenie pomocou jednotlivých typov zabezpečenia. Ak sa používa zabezpečenie s API kľúčom, pri odhlásení aplikácia odosiela žiadosť na API pre odstránenie API kľúča z databázy.

Testovanie API

Na záver sa vykonalo testovanie aplikačného programového rozhrania. Testovanie spočívalo v kontrole jednotlivých koncových bodov. Zámerom bolo zistiť, či koncové body fungujú správne, to znamená, či vracajú v odpovedi dáta, ktoré majú so správnym stavovým kódom, a či sú správne zabezpečené.
Postup pri testovaní
Pri testovaní API, ten kto vykonáva test, nemá prístup ku zdrojovému kódu (black box testovanie). Celý proces sa preto začína naštudovaním dokumentácie návrhu API. Sledujú sa jednotlivé koncové body a to, aké odpovede, dáta a stavové kódy majú vracať pri správnych a aj nesprávnych parametroch žiadosti. Následne sa spraví prvá testovacia žiadosť na API a skúma sa odpoveď. Testovacia žiadosť sa vykoná so správnymi parametrami, ale aj s nesprávnymi (neexistujúce ID aplikácie pri HTTP metóde GET), aby sa skontrolovala odpoveď v obidvoch prípadoch. Správnosť odpovede sa porovnáva s dokumentáciou návrhu API. V poslednom kroku sa manuálne píšu testy. Testy sa píšu pred odoslaním žiadosti a kontrolujú odpoveď na základe toho, aké parametre sa im definovali na testovanie.
Porovnanie použitých programov
Použité boli programy Postman a Testmace. Program Postman bol používaný vo väčšej miere. Má lepšiu dokumentáciu k testom a širšie možnosti použitia. S programom Testmace bolo možné otestovať, či sa v odpovedi nachádza konkrétna hodnota alebo porovnanie hodnôt. Viacej možností testovania bolo prístupných len pre platenú verziu a navyše, dokumentáciu k testovaniu nie je na takej úrovni ako pri programe Postman.
Testovacie scenáre
Spočívali v kontrole koncových bodov pre jednotlivé HTTP metódy a kontrole koncových bodov zabezpečovacích algoritmov. Testovanie bolo rozdelené do dvoch častí: testovanie so správnymi parametrami a testovanie s nesprávnymi parametrami. Rozdelenie je možné vidieť v tabuľke [testScenare].

[testScenare]

HTTP metódy so správne zadanými parametrami
Pre testovanie jednotlivých HTTP metód sa využíval koncový bod /auth/application. V prípade HTTP metód GET a DELETE bolo zadané ID, ktoré sa nachádzalo v tabuľke Aplikácie (Apps) a v pri metódach PUT a POST sa zadávali všetky údaje podľa návrhu API. Tabuľka [testSpravne] bližšie popisuje tieto testovacie scenáre.

[testSpravne]

Algoritmy zabezpečenia so správne zadanými parametrami
Pri testovaní koncových bodov zabezpečovacích algoritmov sa zadávali rôzne overovacie údaje. Pre jednoduchú autentifikáciu sa zadávalo správne meno a heslo, pre webový token JSON správny token, pre overenie API kľúčom správny kľúč API a pre OAuth 2.0 token vygenerovaný serverom tretej strany. Kontrolovalo sa, či overenie prebehlo správne a následné presmerovanie na požadovaný koncový bod. Testovacie scenáre zobrazuje tabuľka [testSec1].

[testSec1]

	Kategória	Popis	Výsledok
BS1	Jednoduchá Autentifikácia	Zadané meno a heslo, \\testovanie času odpovede \\a testovanie vráteného stavového kódu 200.	Funguje správne
BS2	Webový token JSON	Zadaný token, testovanie času odpovede a testovanie vráteného stavového kódu 200.	Funguje správne
BS3	API Klúč	adaný kľúč API, testovanie času odpovede a testovanie vráteného stavového kódu 201.	Funguje správne
BS4	OAuth 2.0	Zadaný token serveru tretej strany, testovanie času odpovede a testovanie vráteného stavového kódu 200.	Funguje správne

Ukážka kódu testovania so správne zadanými parametrami
Na ukážke kódu [testCode] je možné vidieť testovanie HTTP metódy GET pri zadaní správneho ID, ktoré sa nachádza v tabuľke Aplikácie (Apps). V prvom teste sa kontrolovalo, či stavový kód odpovede je 200 (OK), a či telo odpovede je vo formáte JSON. Ďalšie testy kontrolovali hlavičku odpovede a rýchlosť odpovede, ktorá mala byť menej ako 200ms. Nasledujúci test kontroloval, či zadané ID aplikácie sa rovná ID aplikácii v odpovedi. Ako posledné sa porovnávalo ID servera, ktoré je priradené k aplikácií, s ID v odpovedi. Tým sa skontrolovala správnosť vybratých údajov z databázy.

pm.test("Status Code is 200 and has JSON body", () => {
  pm.response.to.not.be.error;
  pm.response.to.have.status(200);
  pm.response.to.have.jsonBody();
  pm.response.to.not.have.jsonBody("error");
});
pm.test("Content-Type is present and is 
        equal to application/json", () => {
  pm.response.to.have.header("Content-Type");
  pm.expect(pm.response.headers.get("Content-Type")).to.eql(
    "application/json; charset=utf-8"
  );
});
pm.test("Response time is less than 200ms", () => {
  pm.expect(pm.response.responseTime).to.be.below(200);
});
pm.test("Path ID is equal to response ID", () => {
  let pathNum = pm.request.url.getPath();
  let jsonData = pm.response.json();
  let appId = jsonData[0].apps.id;
  pm.expect(appId).to.eql(parseInt(pathNum[25]));
});

pm.test("Apps server_id is equal to Servers id", () => {
  let jsonData = pm.response.json();
  let appsServerId = jsonData[0].apps.server_id;
  let serverId = jsonData[0].servers.id;
  pm.expect(appsServerId).to.eql(serverId);
});

[testCode]

HTTP metódy s nesprávne zadanými parametrami
Testovanie prebiehalo podobne ako pri testovaní so správnymi parametrami s tým rozdielom, že pri HTTP metódach GET a DELETE sa zadalo ID, ktoré sa nenachádza v tabuľke Aplikácie (Apps). Pre HTTP metódy PUT a POST sa vynechal jeden údaj potrebný pre správne vykonanie metódy. Popísane testovacie scenáre je možné vidieť v tabuľke [testNesp]

[testNesp]

	Kategória	Popis	Výsledok
HN1	HTTP metóda GET	Testovanie vrátenia chybového hlásenia, \\testovanie času odpovede \\a testovanie vráteného stavového kódu 400.	Funguje správne
HN2	HTTP metóda PUT	Testovanie vrátenia chybového hlásenia, \\testovanie času odpovede \\a testovanie vráteného stavového kódu 400.	Funguje správne
HN3	HTTP metóda POST	Testovanie vrátenia chybového hlásenia, \\testovanie času odpovede \\a testovanie vráteného stavového kódu 400.	Vracia nesprávne \\chybové hlásenie
HN4	HTTP metóda DELETE	Testovanie vrátenia chybového hlásenia, \\testovanie času odpovede \\a testovanie vráteného stavového kódu 400.	Funguje správne

Algoritmy zabezpečenia s nesprávne zadanými parametrami
Pre testovanie koncových bodov zabezpečovacích algoritmov sa vyplnili nesprávne overovacie údaje alebo sa nevyplnili žiadne overovacie údaje. Tým sa overilo správne fungovanie zabezpečenia API v prípade, že by sa chcel niekto do systému dostať s nesprávnymi údajmi. Tabuľka [testSec2] bližšie špecifikuje testovacie scenáre.

[testSec2]

	Kategória	Popis	Výsledok
BN1	Jednoduchá \\Autentifikácia	Zadané nesprávne meno a heslo, testovanie času odpovede a testovanie vráteného stavového kódu 401.	Funguje správne
BN2	Webový token JSON	Zadaný nesprávny token, testovanie času odpovede a testovanie vráteného stavového kódu 401.	Vracia nesprávny stavový kód
BN3	API Klúč	Zadaný nesprávny API kľúč, testovanie času odpovede a testovanie vráteného stavového kódu 401.	Funguje správne
BN4	OAuth 2.0	Zadaný nesprávny token serveru tretej strany, testovanie času odpovede a testovanie vráteného stavového kódu 401.	Funguje správne

Ukážka kódu testovania s nesprávne zadanými parametrami
Ukážka kód [testCode2] zobrazuje HTTP metódu GET s nesprávne zadanými parametrami. Stavový kód sa testoval na kód 400 (nesprávna žiadosť) a telo odpovede muselo obsahovať chybové hlásenie a správu o tomto hlásení.

pm.test("Status Code is 400 and has JSON body", () => {
  pm.response.to.be.error;
  pm.response.to.have.status(400);
  pm.response.to.have.jsonBody();
  pm.response.to.have.jsonBody("error");
});

pm.test("Content-Type is present and 
        is equal to application/json", () => {
  pm.response.to.have.header("Content-Type");
  pm.expect(pm.response.headers.get("Content-Type")).to.eql(
    "application/json; charset=utf-8"
  );
});

pm.test("In response is error message and 
        response time is less than 200ms", () => {
    let jsonData = pm.response.json();
    pm.expect(jsonData.error).to.have.property('message');
    pm.expect(pm.response.responseTime).to.be.below(200);
  }
);

[testCode2]

Výsledok testovania
Testovaním sa overili koncové body pre HTTP metódy, koncové body pre algoritmy zabezpečenia a zistili sa určité nedostatky. HTTP metóda PUT so správne zadanými parametrami vracala nesprávny stavový kód, HTTP metóda POST s nesprávne zadanými parametrami vracala nesprávne chybové hlásenie a koncový bod pre webový token JSON s nesprávne zadanými parametrami vracal nesprávny stavový kód. Tieto chyby nevytvárali závažný funkcionálny alebo zabezpečovací problém, boli v kóde odstránené a nahradené správnymi údajmi podľa návrhu API. Po následnom testovaní všetky koncové body spĺňali kritériá návrhu.

Záver

Zámerom bakalárskej práce bolo navrhnúť aplikačné programové rozhranie, vhodne ho zabezpečiť a otestovať. Pri zabezpečení bolo využitých viacero zabezpečovacích algoritmov, a to jednoduchá autentifikácia, API kľúč, webový token JSON a OAuth 2.0. Testovanie prebiehalo na základe špecifikácie určenej pri návrhu s využitím programov Postman a Testmace a programovacieho jazyka JavaScript. Funkčnosť zabezpečenia aplikačného programového rozhrania bolo potrebné preukázať vhodným spôsobom, preto bola vytvorená aplikačná časť vo frameworku Angular, ktorá s navrhnutým aplikačným programovým rozhraním komunikovala.
V úvode bakalárskej práce bolo potrebné oboznámiť sa s tým, ako aplikačné programové rozhranie funguje a ako sa navrhuje. Teoretické poznatky získané pre návrh boli veľmi dôležité, pretože každé aplikačné programové rozhranie musí spĺňať určité kritéria na základe špecifikácie. Ďalším krokom bolo oboznámenie sa s testovaním, a to konkrétne aké metódy je možné využiť a pomocou akých programov tieto metódy aplikovať. Teoretické poznatky bolo potrebné získať aj z oblasti zabezpečenia. To zahŕňalo identifikáciu najviac využívaných zabezpečovacích algoritmov, ich fungovanie a možnosti integrácie. Ďalej nasledovala analýza aplikácie, kde sa vytvoril dátový model, určili sa funkčné a nefunkčné požiadavky pre aplikačné programové rozhranie a aj pre aplikačnú časť. Na záver bolo potrebné vybrať vhodné technológie pre návrh a implementáciu aplikačného programového rozhrania, pre aplikačnú časť a testovanie. Následne samotný návrh a implementáciu zrealizovať.
Výsledkom práce je funkčná aplikácia s možnosťou výberu zabezpečenia. Aplikácia komunikuje s aplikačným programovým rozhraním, ktorého funkcionalita bola otestovaná na základe testov funkčnosti a bezpečnosti.

Zoznam použitej literatúry

[1] Altexsoft blog. What is API: Definition, Types, Specifications, Documentation. url: https://www.altexsoft.com/blog/engineering/what-is-api-definition-types-specifications-documentation/. (vyhľadané: 8.12.2019).

[2] Alerta blog. Different types of Application Program Interfaces (APIs). url: https://www.alertra.com/articles/different-types-application-program-interfaces-apis. (vyhľadané: 8.12.2019).

[3] MuleSoft. What is a REST API. url: https://www.mulesoft.com/resources/api/what-is-rest-api-design. (vyhľadané: 27.12.2019).

[4] World Wide Web Consortium. Relationship to the World Wide Web and REST Architectures. url: https://www.w3.org/TR/2004/NOTE-ws-arch-20040211/#relwwwrest. (vyhľadané: 8.12.2019).

[5] Roy Fielding. Request Methods. url: https://tools.ietf.org/html/rfc7231#section-4. (vyhľadané: 8.12.2019).

[6] Fermesk Rashidi. What is RESTful API? url: https://www.doprax.com/content/What-is-restful-API. (vyhľadané: 20.12.2019).

[7] TheHungryBrain. REST API Architectural Constraints. url: https://www.geeksforgeeks.org/rest-api-architectural-constraints/. (vyhľadané: 27.12.2019).

[8] SmartBear. API Endpoints - What Are They? Why Do They Matter? url: https://smartbear.com/learn/performance-monitoring/api-endpoints/. (vyhľadané: 27.12.2019).

[9] Dilanka Muthukumarana. RESTful API Design Best Practices. url: https://medium.com/@dilankam/restful-api-design-best-practices-principles-ded471f573f3. (vyhľadané: 27.12.2019).

[10] J. Gettys a kol. R. Fielding UC. Irvine. HTTP Message. url: https://www.w3.org/Protocols/rfc2616/rfc2616.html. (vyhľadané: 21.12.2019).

[11] RestfulApi contributors. REST API. url: https://restfulapi.net/. (vyhľadané: 21.12.2019).

[12] MDN contributors. HTTP request methods. url: https://developer.mozilla.org/en-US/docs/Web/HTTP/Methods. (vyhľadané: 20.12.2019).

[13] WHATWG community. Forms. url: https://html.spec.whatwg.org/multipage/forms.html. (vyhľadané: 21.12.2019).

[14] SmartBear Team. What is API testing. url: https://smartbear.com/solutions/api-testing/. (vyhľadané: 18.3.2020).

[15] Katalon Team. API Testing. url: https://www.katalon.com/api-testing/ (vyhľadané: 18.3.2020).

[16] Guru99 Team. Testing. url: https://www.guru99.com/testing. (vyhľadané: 18.3.2020).

[17] TestingHelp community. Reliability Testing. url: https://www.softwaretestinghelp.com/reliability-testing/. (vyhľadané: 18.3.2020).

[18] Margaret Rouse. Authentication. url: https://searchsecurity.techtarget.com/definition/authentication. (vyhľadané: 15.1.2020).

[19] Joseph Dunno. Autorizácia a autentifikácia v modernom webovom priestore. url: https://www.odyzeo.com/blog/autorizacia-a-autentifikacia-v-modernom-webovom-priestore. (vyhľadané: 15.1.2020).

[20] RestCase contributors. REST API and beyond. url: https://blog.restcase.com/ (vyhľadané: 15.1.2020).

[21] Kristopher Sandoval. 3 Common Methods of API Authentication Explained. url: https://nordicapis.com/3-common-methods-api-authentication-explained/. (vyhľadané: 15.1.2020).

[22] JWT documentation. Introduction to JSON Web Tokens. url: https://jwt.io/introduction/. (vyhľadané: 15.1.2020).

[23] Rob Sobers. What is OAuth? Definition and How it Works. url: https://www.varonis.com/blog/what-is-oauth/. (vyhľadané: 15.1.2020).

[24] Synopsys Editorial Team. What’s the difference? OAuth 1.0 vs OAuth 2.0. url: https://www.synopsys.com/blogs/software-security/oauth-2-0-vs-oauth-1-0/. (vyhľadané: 15.1.2020).

Návrh a implementácia aplikácie SAPI

Obsah

Použité technológie

Návrh a tvorba API

Aplikačná časť

Testovanie

Implementácia aplikácie SAPI

Aplikačné programové rozhranie

Aplikačná časť

Testovanie API

Záver

Zoznam použitej literatúry

Navigačné menu

Osobné nástroje

Menné priestory

Varianty

Zobrazenia

Viac

Hľadať

Navigácia

Rýchle linky

Nástroje