Mielőtt megtanultam volna a szoftverfejlesztést, az API egyfajta sörnek hangzott.
Ma olyan gyakran használom a kifejezést, hogy nemrégiben megpróbáltam API-t rendelni egy bárban.
A csapos válasza az volt, hogy dobott egy 404: erőforrást nem található.
Sok emberrel találkozom, mind a technikában, mind máshol, akiknek meglehetősen homályos vagy téves elképzeléseik vannak arról, hogy mit is jelent ez a meglehetősen gyakori kifejezés.
Technikailag az API az Application Programming Interface rövidítést jelenti . Valamelyik pillanatban a legtöbb nagyvállalat API-kat épített ügyfeleinek, vagy belső használatra.
De hogyan magyarázza az API-t egyszerű angolul? És van-e tágabb értelemben, mint a fejlesztésben és az üzleti életben? Először húzzuk vissza, és nézzük meg, hogyan működik maga a web.
WWW és távoli szerverek
Ha az internetre gondolok, akkor nagy összekapcsolt szerverek hálózatát képzelem el .
Az internet minden oldala valahol egy távoli szerveren van tárolva. A távoli szerver mégsem olyan misztikus - csupán egy távoli számítógép része, amely a kérések feldolgozására van optimalizálva.
Ahhoz, hogy a dolgokat perspektívába helyezhesse, felpörgethet egy laptopot egy olyan szerverrel, amely egy teljes webhelyet képes kiszolgálni az interneten (valójában egy helyi szervert használnak a mérnökök a weboldalak fejlesztéséhez, mielőtt azokat nyilvánosság elé terjesztenék).
Amikor beírja a www.facebook.com webhelyet a böngészőbe, egy kérés érkezik a Facebook távoli szerverére. Amint a böngésző megkapja a választ, értelmezi a kódot, és megjeleníti az oldalt.
A böngésző, más néven kliens számára a Facebook szervere API. Ez azt jelenti, hogy minden alkalommal, amikor meglátogat egy weboldalt, kapcsolatba lép valamilyen távoli kiszolgáló API-val.
Az API nem azonos a távoli kiszolgálóval - inkább a kiszolgáló azon része, amely kéréseket fogad és válaszokat küld .
Az API-k az ügyfelek kiszolgálásának egyik módja
Valószínűleg hallott már arról, hogy az API-k termékként csomagolják a vállalatokat. Például a Weather Underground eladja az időjárási adatok API-jához való hozzáférést.
Példa a forgatókönyvre: A kisvállalkozás webhelyén található egy űrlap, amellyel az ügyfeleket regisztrálhatja a találkozókra. Lehetőséget kíván adni ügyfeleinek, hogy automatikusan létrehozzák a Google naptáreseményét az adott találkozó részleteivel.
API használat: Az az elképzelés, hogy webhelye szervere közvetlenül a Google szerverével beszéljen, kérve egy esemény létrehozását a megadott adatokkal. A szervere ekkor megkapja a Google válaszát, feldolgozza azt, és visszaküldi a böngészőnek a releváns információkat, például egy megerősítő üzenetet a felhasználónak.
Alternatív megoldásként a böngésző gyakran küldhet API-kérést közvetlenül a Google szerverére, megkerülve a szervert.
Miben különbözik ez a Google Naptár API-ja bármely más távoli szerver API-jától?
Technikai értelemben a különbség a kérés és a válasz formátuma.
A teljes weboldal megjelenítéséhez böngészője HTML-re vár választ , amely bemutató kódot tartalmaz, míg a Google Naptár API-hívása csak visszaadja az adatokat - valószínűleg olyan formátumban, mint a JSON .
Ha a webhely szervere megküldi az API kérést, akkor a webhely szervere az ügyfél (hasonlóan ahhoz, mint a böngészője az ügyfél, amikor azt egy webhelyre való navigáláshoz használja).
A felhasználók szempontjából az API-k lehetővé teszik számukra a művelet végrehajtását anélkül, hogy elhagynák a webhelyet.
A legtöbb modern webhely legalább néhány külső API-t fogyaszt.
Sok problémára már van harmadik féltől származó megoldás, legyen az könyvtár vagy szolgáltatás. Gyakran egyszerűbb és megbízhatóbb egy meglévő megoldás használata.
Nem ritka, hogy a fejlesztői csapatok alkalmazásukat több szerverre bontják, amelyek API-kon keresztül beszélnek egymással. Azokat a kiszolgálókat, amelyek a fő alkalmazáskiszolgáló számára segítõ funkciókat hajtanak végre, általában mikroszolgáltatásoknak nevezzük .
Összefoglalva, ha egy vállalat API-t kínál ügyfeleinek, ez csak azt jelenti, hogy dedikált URL-eket építettek, amelyek tiszta adatválaszokat adnak vissza - vagyis a válaszok nem tartalmazzák azt a fajta prezentációs költséget, mint amire egy grafikus felhasználói felület, mint egy weboldal .
Meg tudja-e tenni ezeket a kéréseket a böngészőjével? Gyakran igen. Mivel a tényleges HTTP-átvitel szöveges formában történik, a böngésző mindig a lehető legjobban megteszi a válasz megjelenítését.
Például közvetlenül elérheti a GitHub API-ját a böngészőjével anélkül, hogy hozzáférési tokenre lenne szüksége. Íme a JSON válasz, amelyet akkor kap, amikor meglátogatja a GitHub felhasználói API útvonalát a böngészőben (//api.github.com/users/petrgazarov):
{ "login": "petrgazarov", "id": 5581195, "avatar_url": "//avatars.githubusercontent.com/u/5581195?v=3", "gravatar_id": "", "url": "//api.github.com/users/petrgazarov", "html_url": "//github.com/petrgazarov", "followers_url": "//api.github.com/users/petrgazarov/followers", "following_url": "//api.github.com/users/petrgazarov/following{/other_user}", "gists_url": "//api.github.com/users/petrgazarov/gists{/gist_id}", "starred_url": "//api.github.com/users/petrgazarov/starred{/owner}{/repo}", "subscriptions_url": "//api.github.com/users/petrgazarov/subscriptions", "organizations_url": "//api.github.com/users/petrgazarov/orgs", "repos_url": "//api.github.com/users/petrgazarov/repos", "events_url": "//api.github.com/users/petrgazarov/events{/privacy}", "received_events_url": "//api.github.com/users/petrgazarov/received_events", "type": "User", "site_admin": false, "name": "Petr Gazarov", "company": "PolicyGenius", "blog": "//petrgazarov.com/", "location": "NYC", "email": "[email protected]", "hireable": null, "bio": null, "public_repos": 23, "public_gists": 0, "followers": 7, "following": 14, "created_at": "2013-10-01T00:33:23Z", "updated_at": "2016-08-02T05:44:01Z"}Úgy tűnik, hogy a böngésző jól teljesítette a JSON válasz megjelenítését. Az ilyen JSON-válasz készen áll a kód használatára. Könnyű kinyerni az adatokat ebből a szövegből. Akkor bármit megtehet az adatokkal.
A „Alkalmazás”
Zárásként dobjunk be még néhány példát az API-król.
Az „alkalmazás” sok mindenre utalhat. Íme néhány az API összefüggésében:
- Különálló funkciójú szoftver.
- Az egész szerver, az egész alkalmazás, vagy csak egy alkalmazás kis része.
Alapvetően bármely szoftver, amely megkülönböztethető a környezetétől, lehet „A” az API-ban, és valószínűleg valamilyen API is lesz.
Tegyük fel, hogy harmadik fél könyvtárát használja a kódjában. Miután beépítette a kódjába, a könyvtár az általános alkalmazás részévé válik. Különálló szoftverelemként a könyvtár valószínűleg rendelkezik API-val, amely lehetővé teszi, hogy kölcsönhatásba lépjen a többi kóddal.
Itt van egy másik példa: Az Object Oriented Design alkalmazásban a kód objektumokba rendeződik. Az alkalmazás több száz olyan objektumot határozhat meg, amelyek kölcsönhatásba léphetnek egymással.
Minden objektum rendelkezik API-val - nyilvános módszerek és tulajdonságok halmazával, amelyeket interakcióra használ az alkalmazás többi objektumával.
An object may also have inner logic that is private, meaning that it’shiddenfrom the outside scope (and not an API).
From what we have covered, I hope you take away the broader meaning of API as well as the more common uses of the term today.
Interesting Resources (stuff that I left out but is still very cool):
A great youtube video on DNS (Domain Name System)
HTTP protocol basics
An Awesome Khan Academy video on Object Oriented Design Principles