API Application Programming Interface

 Az API az angol „application programming interface” kifejezés rövidítése, ami magyarul „alkalmazásprogramozási felületet” jelent. Az API-k a szoftverfejlesztők munkáját hivatottak megkönnyíteni azzal, hogy hozzáférést biztosítanak egy adott szoftver vagy eszköz utasításkészletéhez.

Az API olyan, mint amikor össze akarsz rakni egy új gépet. Tud az alkotóelemek nevét, és van hozzá leírás is, hogy pl intel proci, ssd stb. Tudod mire jó, mit tud, de azt nem kell tudnod, mennyi réz kell a legyártáshoz.

Ha választasz egy utasítást az API-ból, akkor nem kell tudnod, hogy pontosan mi történik a színfalak mögött – például hogy egy Android telefon hogyan jelenít meg egy üzenetet a képernyőn – csak a megfelelő parancsot kell kiválasztania az API-ból, ami elvégzi ezt helyette.

Az API-k rengeteg időt spórolnak meg a programozók számára, hiszen elég csak megadniuk a parancsokat, és a munka nagy részét az a platform végzi majd, amire éppen fejlesztenek. Mindez a forráskódot is átláthatóbbá teszi, és így egy azonos platformra készült több alkalmazás is hasonló utasításkészlettel rendelkezik majd, ami megkönnyítheti a hibaelhárítást.

Tegyük fel, hogy egy alkalmazást akarsz írni Android telóra. Az Androidhoz rengeteg API érhető el, mint ahogy az összes többi mobilos és számítógépes operációs rendszerhez is (Windows, iOS, stb.)

Ha szeretnéd, hogy az alkalmazásod képes legyen használni a készülék fényképezőjét, akkor nem kell külön írnod egy programot csak ezért, mert használhatod az Android kameravezérlő API-ját. Ugyan így elhelyezhetsz alkalmazásodban egy böngészőt is, és temérdek más funkciót, illetve eszközt, amit az Android támogat.

API-k nélkül sokkal tovább tartana elkészíteni még a legegyszerűbb mobilalkalmazásokat és számítógépes szoftvereket is, mert a programozóknak saját maguktól kellene olyan programkódokat írniuk, amelyek tökéletesen képesek kommunikálni az adott platform szoftveres és hardveres alkotóelemeivel.

Egy másik előny, hogy valahányszor a platform tulajdonosa frissíti az API-t (például kijavít egy hibát, vagy hatékonyabbá teszi egy parancs működését), akkor minden olyan alkalmazás frissül ezekkel a változtatásokkal, amik az adott API-val lettek elkészítve.

Az API-kat arra is szokás használni, hogy egy alkalmazás hozzáférhessünk olyan hardveres és szoftveres funkciókhoz, amikre egyébként nem lennénk jogosult. Az API-knak éppen ezért fontos szerepük lehet a biztonságban.

Például amikor egy webhelyet meglátogatva megjelenik az üzenet, hogy a webhely szeretné látni a pontos tartózkodási helyedet, akkor a webhely hozzáférési engedélyt kér tőled a helymeghatározási API használatához böngésződben. A web böngészők azért teszik elérhetővé ezt az API-t a fejlesztők számára, hogy azok könnyedén hozzáférhessenek tartózkodási helyedhez – persze csak ha erre engedélyt adsz. Ha megadod az engedélyt, akkor a böngésző alkalmazás a GPS vagy valamilyen más helymeghatározási módszer segítségével megkeresi, hogy hol vagy, és jelenti ezt a webhelynek.

Az Android használók gyakran találkozhatnak ilyen jellegű üzenetekkel egy újonnan telepített alkalmazás használatakor, például amikor egy applikáció hozzáférést kér a kamera használatához (Instagram), vagy a tárhely eléréséhez (ha fényképet szeretnél feltölteni telefonodról a Facebookra) és így tovább.

Az számítógépes operációs rendszerek is rengeteg API-t használnak, többek között a fájlengedélyek kezelésére is. Egy adott szoftvernek nincs közvetlen hozzáférése a merevlemezen tárolt adatokhoz – kizárólag egy API-n keresztül olvashatja, módosíthatja, vagy törölheti azokat.

Az API-k azonban még ennél is több mindenre használhatók. Ha például láttál már Google Térképet beágyazva egy weboldalon, akkor az az oldal a Google Térkép API-t használja, hogy megjelenítse az adott térképet. Az ilyen API-kat a Google teszi elérhetővé a web fejlesztők számára, akik így könnyedén elhelyezhetnek összetettebb elemeket is webhelyükön ahelyett, hogy valamilyen félmegoldással csapnának rá például egy térképet az egyik oldalra.

Ez biztosítja azt is, hogy ha a Google frissíti az API-t, az összes térképet megjelenítő webhelyen érvénye lépnek a változások.

Számtalan online szolgáltatás és eszköz üzemeltetője kínál API-kat ezek eléréséhez, Így lehet például fordítást kérni a Google Fordítótól, vagy beágyazni egy interaktív Twitter tweetet egy webhelyre.

Az OAuth szabvány például lehetővé teszi, hogy különféle szolgáltatások fiókjaival lépj be más szolgáltatások webhelyére anélkül, hogy ott külön fiókot kellene létrehoznod. Ezért van az, hogy sok helyen látod a „Bejelentkezés Facebookkal” vagy „Bejelentkezés Google-lal” lehetőségeket.

AJAX - Az Ajax (Asynchronous JavaScript and XML) interaktív web alkalmazások létrehozására szolgáló web fejlesztési technika. A weblap kis mennyiségű adatot cserél a szerverrel a háttérben, így a lapot nem kell újratölteni minden egyes alkalommal, amikor a felhasználó módosít valamit. Ez növeli a honlap interaktivitását, sebességét és használhatóságát. (maga a kifejezés 2005-ben született, Jesse James Garett használta először)

A legnyilvánvalóbb ok az Ajax használatára a felhasználói élmény fokozása. Amikor egy linkre kattintás hatására a teljes weboldal újratöltődik, az sokszor időigényes művelet. Az Ajaxot használó oldalak e helyett képesek rá, hogy csak az oldal szükséges részét frissítsék, így gyorsabb reagálást biztosítanak a felhasználói interakciókra. Néhányan úgy gondolják, hogy az Ajax lesz az a feltörekvő technológia, amelynek segítségével a jövőben a webes alkalmazások minden eddiginél interaktívabbá és így széles körben is sokkal népszerűbbé válhatnak.

Az Ajax kérések is azon műveletek közé tartoznak, amelyek nem blokkolják, a szinkron futást nem blokkolják a stacket, hanem a böngésző stack társával párhuzamosan hajtja végre ezt a műveletet és a szerver válasza után futtat további elemeket, amennyiben szinkron működés véget ért. Erre azért van ilyen formában szükség, mert egy ilyen szerver oldali kérés az sok ideig tart, több százmillió miliszekundumig is akár, és addig nem blokkolhatjuk a szinkron futását a kódnak.

Az onreadyStateChange ez mindig lefut akkor amikor a kérésed életciklusában valami változás történik.

Összesen négyen ilyen életciklusa van egy ilyen kérésnek,

https://developer.mozilla.org/hu/docs/Web/API/XMLHttpRequest

XMLHttpRequest.readyState

A kérelem állapotát jelző előjel nélküli számmal tér vissza, amely lehet:

0 - ha a kérés nem inicializált

1 - ha a kapcsolat létrejött a szerverrel

2 - ha a kérés fogadva

3 - ha a kérés feldolgozása folyamatban

4 - ha a kérés kész, válasz kész

 

https://reqres.in/ ez egy ingyenes tesztelő oldal, amit szólongattunk a feladatunkban, és ennek az api-ját fogjuk felhasználni, ahhoz, hogy adathoz jussunk.

Ez egy javatomcat apache szerver, ami ajax kérésekre ad választ nekünk, gyakorlatilag egy adatbázis szerver, ami tök üres adatbázisokat tartalmaz, amiket a kódba beillesztve, az oldalon található funkciókat le tesztelni a fejlesztett oldalunkon. Tehát nagy kimenetele nem lesz, és arra jó, hogy eleve le lehet tesztelni a kódunkat, hogy szintaxisában jó, és ha jól működik, akkor lehet az éles rendszerre ráengedni, amiben valós adatok is lehetnek, így nem tudunk kárt tenni az adatokban.

Ha megnyitod a tesztelő oldalt a böngészőben láthatod, hogy REST API, a REST (Representational State Transfer) egy szoftverarchitektúra típus, elosztott kapcsolat (loose coupling), nagy, internet alapú rendszerek számára, amilyen például a világháló. A Representational State Transfer kifejezést Roy Fielding vezette be és definiálta 2000-ben a doktori disszertációjában. Fielding egyike a HTTP (HyperText Transfer Protocol) specifikáció szerkesztőinek.

Egy REST típusú architektúra kliensekből és szerverekből áll. A kliensek kéréseket indítanak a szerverek felé; a szerverek kéréseket dolgoznak fel és a megfelelő választ küldik vissza. A kérések és a válaszok erőforrás-reprezentációk szállítása köré épülnek. Az erőforrás lényegében bármilyen koherens(pl ajax kérés, vagy egy php modulus, amikor php-be kérdezünk le, attól függően, hogy miben íródik az oldal, ami a kapcsolatot felveszi a szerverrel) és értelmesen címezhető koncepció lehet. Egy erőforrás-reprezentáció általában egy dokumentum, mely rögzíti az erőforrás jelenlegi vagy kívánt állapotát. Vagy java szervert, vagy mysql-t szoktak felállítani, és ezzel oldják meg a különböző adatlekéréseket.

Tehát a REST API lényege, hogy több különböző adatbázis szervert tömbösít, és kapcsol össze mivel az adatbázis kiszolgálók a teljesség igénye nélkül lehet Microsoft IIS – Internet Information Server ms sql támogatással. Az ilyen szervereket általában, ASP (ASP (Application Service Providing) - magyarul alkalmazás-szolgáltatás, vagy alkalmazás-bérlet) környezettel szoktál lekérdezni webesen.

A klasszikus kiszolgáló az apach szerver mysql támogatással és php-vel, és itt értelemszerűen mysql parancsokkal lehet operálni, illetve nagyon jellemzően php-vel íródott web kiszolgálására használatos. Van az előbb említett tomcat appach java szerver, ami ajax kéréseket támogat, és ha mondjuk, az előbb felsoroltakat kötik tömbbe, akkor van egy parancs értelmező algoritmus, és amikor érkezik valamilyen adatbázis lekérés, akkor értelemszerűen ahhoz, a szerverhez fogja továbbítani a csomagot, amelyik ezt tudja értelmezni és meg tudja válaszolni. Pl. egy ajaxot a tomcathez küld, a php-t a mysql-hez küldi stb.

Jellemzően ezek tárhely szolgáltatóknál szoktak lenni, amikor a tárhely szolgáltató valamilyen felületen, pl webes felületen lehetőséget biztosít a felhasználó számára, hogy bármilyen webes fejlesztést készítsen.

Ezek nemcsak adatbázis szerverek, hanem kapcsolt Simple Mail Transport Protocoll – SMPT szolgáltatással is rendelkeznek, amelynek az a lényege, ha pl csinálunk egy weboldalt, amin mondjuk egy regisztrációt kell a felhasználónak tennie, akkor tudjon neki egy mailt küldeni, az általa megadott e-mail címre, hogy erősítse meg a regisztrációját. Vagy pl egy web shopnál a rendelések visszaigazolása e-mailbe. Mailt- küld magyarul. Ahhoz, hogy a mail ne legyen spam szüksége van az adatbázisnak megörökölni a beállított domain nevet. A beállított domain névhez kapcsolódó mx rekord segítségével az smtp –re ülő dovecat-el oldja meg a mail hitelesítését. Magyarul, ha a weboldalunk regisztrált domain neve a pulikutya.hu akkor a hozzá kapcsolódó mail.pulikutya.hu mx rekordhoz hozzá köti az adatbázisból érkező smtp kérést vagyis levelet küld a domain nevünknek megfelelő hitelesítő e-mailcímmel.

Nézzük az oldalon a postot: https://reqres.in/

Ez két útvonalat biztosít, ami számunkra most releváns, ezt a POST (katt az oldalon a post gomb - create mellett) method-dal megszólítható login útvonalat, ahová, ha a body-ban olyan adatokat küldünk, ami itt az Request alatt látható (morpheus, leader) akkor ő egy olyen token-nel, fog válaszolni mint amit a Response alatt láthatunk, ami egy olyan kulcs, amellyel elérhetjük az összes többi erőforrást, tehát hitelesítjük az adatkapcsolatunkat.

A token olyan biztonsági kulcs, ami titkosítja a webes felhasználói accountokhoz szükséges belépéseket és a belépés után történő különböző adatbázis kéréseket, pl regisztráció, vagy weboldal szerkesztő felületének megnyitása.

A token szolgáltatás egy ráépülő modul, ami alapértelmezetten mondjuk egy weblapra belépéshez nem kötelező, de biztonsági szempontból ajánlott szolgáltatási felület.

pl: hogyha készítesz egy keretrendszerrel pl drupal-al egy oldalt, a drupalba és egyúttal az adatbázishoz való hozzáféréshez nincs másra szükség, minthogy beírd a domain nevet/?=user, ami a drupal „white paper”-jében megtalálható. Tehát, ahonnan a drupal webkeretrendszer letölthető és aztán a weboldalunkon telepítettük, egyértelműen leírják, hogy hogyan milyen módon lehet bejelentkezni. Éppen ezért mivel ez bárki számára elérhető információ, így aki a webodalunkat fel akarja törni, nincs más dolga, mint követni a fenti utasítást, beírja az url-t a kapcsolókat és próbálkozik, felhasználó név és jelszó párossal bejelentkezni. A profik erre egy algoritmust használnak, az algoritmus lényege az, hogy egy robot segítségével egy gyűjtő oldalon megtalálható adatbázisból, ahol a leggyakrabban használt 10.000 felhasználó név és jelszó párost végig próbálgatja a rendszerünkön így valószínűleg 2-3 nap alatt sikeresen bejut a weboldalunkra és az ott általunk nem kívánt tartalmakat is megoszthat, mivel a weboldallal az adatbázissal is közvetlenül hozzá fér. Ha a weboldalunkat tokennel látjuk el, akkor a próbálkozások el fognak maradni. Mivel az alapértelmezett belépés nem fog működni, hiszen a szerver várja az alapinformációkat, amire egy tokennel válaszolna, és mivel aki be akar lépni ezt a tokent nem ismeri így nem jut el a bejelentkezési oldalig sem. pl a forpsi alapból ad, ez szerver szinten működik, de be lehet ágyazni a weboldalba is, de oda csak akkor tudjuk beágyazni, ha a szerver erre fel van készítve. De profi szolgáltatók kapásból megadják ezt a lehetőséget kérni sem kell.

Tehát a koncepció az az, hogy védett erőforrásokhoz akarunk hozzá férni, és ehhez előtte meg kell kaparintanunk ezt a tokent. Ha megvan ez a token, akkor ki kell küldenünk egy újabb kérést, ezt a sendrequest functiont kétszer kell tulajdonképpen ilyen módon meghívni és meg kell szólítanunk ezt a list.users (katt az elősre), amiben ilyen felhasználó adatokhoz juthatunk.

A kliensről post methoddal küldünk requestet, a bejelentkezési adatokkal a szerver oldalra. A szerver egy tokennel válaszol, és ezt a tokent hozzá csaphatjuk a header információhoz, de a user útvonal úgy is válaszol ha a tokent nem csapjuk hozzá a header-ekhez, a való életben szokás hozzá csatolni. Ez a users erőforrás fog a felhasználók listájával válaszolni. Tehát ezzel a védett erőforrással. Itt az a fontos az egészben, hogy az első kérésünktől függ a második kérés. Csak akkor tudod megküldeni ezt a get kérést, a users útvonalra, ha már előtte hozzá jutottál a tokenhez.

Alap AJAX hívások

·       A let xhttp = new XMLHttpRequest(); - Új kérés (XMLHttpRequest) objektum létrehozása.

·       A xhttp.onreadystatechange = function() - Ha változik a kérés (XMLHttpRequest) állapota, meghívódik a függvény (function).

·       A xhttp.readyState == 4 - Lezajlott a kérés, és megérkezett a válasz.

·       A xhttp.status == 200 - Létezik a kért objektum (fájl). Ha nem létezik, a status értéke 404 (Page not found).

·       A xhttp.responseText - A válasz szöveges tartalma.

·       A xhttp.open("GET", "aj_01.txt", true); - A kérés összeállítása (metódus, url, aszinkron)

-        metódus: GET vagy POST

-        url: a fájl megadása (útvonallal)

-        aszinkron: true vagy false

·       A xhttp.send(); - A kérés elküldése.

·      

Ha a válaszként kapott szövegben formázó utasítások vannak, feldolgozásra kerülnek megjelenítéskor!