Mis on API? Inglise keeles Palun.

Enne tarkvaraarenduse õppimist kõlas API nagu omamoodi õlu.

Täna kasutan seda terminit nii tihti, et olen tegelikult hiljuti proovinud baarist API-d tellida.

Baarmeni vastus oli visata 404: ressurssi ei leitud.

Kohtun paljude inimestega, kes töötavad nii tehnikas kui mujal, kellel on üsna ebamäärane või vale ettekujutus selle üsna levinud mõiste tähendusest.

Tehniliselt tähendab API rakenduse programmeerimisliidest . Ühel või teisel hetkel on enamik suurettevõtteid loonud API-sid oma klientidele või sisekasutuseks.

Aga kuidas seletada API-d lihtsas inglise keeles? Ja kas sellel on laiem tähendus kui arenduses ja ettevõtluses kasutatav? Kõigepealt tõmbame tagasi ja vaatame, kuidas veeb ise töötab.

WWW ja kaugserverid

Veebile mõeldes kujutan ette suurt ühendatud serverite võrku .

Iga Interneti-leht on kuskil kaugserveris. Kaugserver pole ju nii müstiline - see on vaid osa kaugelt asetsevast arvutist, mis on optimeeritud taotluste töötlemiseks.

Asjade perspektiivikaks muutmiseks võite oma sülearvutis luua serveri, mis on võimeline kogu veebisaiti veebis teenima (tegelikult on kohalik server see, mida insenerid kasutavad veebisaitide arendamiseks enne nende avalikkusele avaldamist).

Kui tippite oma brauserisse www.facebook.com, läheb päring välja Facebooki kaugserverisse. Kui teie brauser saab vastuse, tõlgendab see koodi ja kuvab lehe.

Brauserile, mida nimetatakse ka kliendiks , on Facebooki server API. See tähendab, et iga kord, kui külastate mõnda veebilehte, suhtlete mõne kaugserveri API-ga.

API pole sama mis kaugserver - pigem on see serveri osa, mis võtab vastu päringuid ja saadab vastuseid .

API-d kui viis klientide teenindamiseks

Ilmselt olete kuulnud ettevõtetest, kes pakendavad API-sid toodetena. Näiteks müüb Weather Underground juurdepääsu oma ilmaandmete API-le.

Stsenaariumi näide: Teie väikeettevõtte veebisaidil on vorm, mida kasutatakse klientide kohtumistele registreerimiseks. Soovite anda oma klientidele võimaluse automaatselt luua Google'i kalendrisündmus koos selle kohtumise üksikasjadega.

API kasutamine: idee on lasta oma veebisaidi serveril rääkida otse Google'i serveriga, paludes luua antud üksikasjadega sündmus. Teie server saaks siis Google'i vastuse, töötleb seda ja saadab brauserile tagasi asjakohase teabe, näiteks kinnituskirja kasutajale.

Teise võimalusena võib teie brauser saata API-päringu teie serverist mööda minnes otse Google'i serverile.

Mille poolest erineb see Google'i kalendri API mis tahes muu seal asuva kaugserveri API-st?

Tehnilises mõttes on erinevus taotluse ja vastuse vormingus.

Kogu veebilehe renderdamiseks loodab teie brauser HTML-is vastust , mis sisaldab esitluskoodi, samas kui Google'i kalendri API-kõne tagastaks lihtsalt andmed - tõenäoliselt sellises vormingus nagu JSON .

Kui teie veebisaidi server esitab API-päringu, on teie veebisaidi server klient (sarnane teie brauseri kliendiga, kui kasutate seda veebisaidile navigeerimiseks).

Teie kasutajate vaatevinklist võimaldavad API-d neil toimingu lõpule viia teie veebisaidilt lahkumata.

Enamik kaasaegseid veebisaite tarbib vähemalt mõnda kolmanda osapoole API-d.

Paljudel probleemidel on juba kolmanda osapoole lahendus, olgu see siis raamatukogu või teenuse näol. Sageli on olemasoleva lahenduse kasutamine lihtsalt lihtsam ja usaldusväärsem.

Pole haruldane, et arendusmeeskonnad jagavad oma rakenduse mitmeks serveriks, mis räägivad omavahel API-de kaudu. Servereid, mis täidavad põhirakendusserveri abifunktsioone, nimetatakse tavaliselt mikroteenusteks .

Kokkuvõtteks võib öelda, et kui ettevõte pakub oma klientidele API-d, tähendab see lihtsalt seda, et nad on loonud spetsiaalsete URL-ide komplekti, mis tagastavad puhtad andmevastused - see tähendab, et vastused ei sisalda sellist esitlust, mida võiksite oodata graafiline kasutajaliides nagu veebisait .

Kas saate neid taotlusi oma brauseriga esitada? Sageli jah. Kuna tegelik HTTP-edastus toimub tekstis, teeb teie brauser vastuse kuvamiseks alati parima.

Näiteks saate oma brauseriga otse GitHubi API-le juurde pääseda, ilma et peaksite isegi juurdepääsuluba vajama. Siin on JSON-vastus, mille saate, kui külastate oma brauseris GitHubi kasutaja API-marsruuti (//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"}

Tundub, et brauser on JSON-i vastuse kuvamisega kenasti hakkama saanud. Selline JSON-i vastus on teie koodis kasutamiseks valmis. Sellest tekstist on lihtne andmeid välja võtta. Siis saate andmetega teha mida iganes soovite.

A on rakenduse jaoks

Lõpetuseks viskame veel paar API-näite.

Rakendus võib viidata paljudele asjadele. Siin on mõned neist API kontekstis:

  1. Teatud funktsiooniga tarkvara.
  2. Kogu server, kogu rakendus või lihtsalt väike osa rakendusest.

Põhimõtteliselt võib iga tarkvara, mida saab keskkonnast eristavalt eraldada, olla API-s täht A ja tõenäoliselt omada ka mingit API-d.

Oletame, et kasutate oma koodis kolmanda osapoole teeki. Kui teie kood on integreeritud, saab kogu teie rakenduse osaks kogu. Kuna teegil on eraldi tarkvara, on raamatukogul tõenäoliselt API, mis võimaldab tal ülejäänud koodiga suhelda.

Siin on veel üks näide: Object Oriented Designis on kood korraldatud objektideks. Teie rakendusel võib olla määratletud sadu objekte, mis saavad üksteisega suhelda.

Igal objektil on API - avalike meetodite ja omaduste kogum, mida ta kasutab teie rakenduses teiste objektidega suhtlemiseks.

Objektil võib olla ka privaatne sisemine loogika , mis tähendab, et see onvarjatudväljastpoolt (ja mitte API).

Sellest, mida oleme käsitlenud, loodan, et võtate ära nii API laiema tähenduse kui ka selle sõna tänapäeval levinumad kasutused.

Huvitavad ressursid (värk, mille jätsin välja, kuid on siiski väga lahe):

Suurepärane YouTube'i video DNS-is (domeeninimede süsteem)

HTTP-protokolli põhitõed

Äge Khani akadeemia video objektile suunatud disaini põhimõtetest