Kaj je API? V angleščini prosim.

Preden sem se naučil razvoja programske opreme, je API zveni kot nekakšno pivo.

Danes izraz uporabljam tako pogosto, da sem pravzaprav pred kratkim poskusil naročiti API v baru.

Barmanov odgovor je bil, da je vrgel 404: vir ni bil najden.

Spoznavam veliko ljudi, ki delajo v tehniki in drugod, ki imajo precej nejasno ali napačno predstavo o tem, kaj pomeni ta dokaj pogost izraz.

Tehnično API pomeni Vmesnik za programiranje aplikacij . V določenem trenutku je večina velikih podjetij zgradila API-je za svoje stranke ali za interno uporabo.

Kako pa razložite API v preprosti angleščini? In ali obstaja širši pomen od tistega, ki se uporablja v razvoju in poslu? Najprej se umaknimo in si oglejmo, kako deluje sam splet.

WWW in oddaljeni strežniki

Ko razmišljam o spletu, si predstavljam veliko mrežo povezanih strežnikov.

Vsaka stran v internetu je shranjena nekje na oddaljenem strežniku. Oddaljeni strežnik navsezadnje ni tako mističen - je le del oddaljenega računalnika, ki je optimiziran za obdelavo zahtev.

Če želite stvari postaviti v perspektivo, lahko na prenosnem računalniku zavrtite strežnik, ki lahko spletnemu mestu servira celotno spletno mesto (pravzaprav lokalni strežnik inženirji uporabljajo za razvoj spletnih mest, preden jih objavijo v javnosti).

Ko v brskalnik vnesete www.facebook.com, se na oddaljeni strežnik Facebooka pošlje zahteva. Ko vaš brskalnik prejme odgovor, interpretira kodo in prikaže stran.

Za brskalnik, znan tudi kot odjemalec , je strežnik Facebook API. To pomeni, da vsakič, ko obiščete spletno stran, komunicirate z API-jem oddaljenega strežnika.

API ni enak oddaljenemu strežniku - prej je del strežnika, ki sprejema zahteve in pošilja odgovore .

API-ji kot način, kako služiti strankam

Verjetno ste že slišali za podjetja, ki API-je pakirajo kot izdelke. Na primer, Weather Underground prodaja dostop do svojega API-ja za vremenske podatke.

Primer scenarija: Spletno mesto vašega malega podjetja ima obrazec za prijavo strank na sestanke. Svojim strankam želite omogočiti, da samodejno ustvarijo dogodek v Google koledarju s podrobnostmi za ta sestanek.

Uporaba API-ja: Ideja je, da strežnik vašega spletnega mesta govori neposredno z Googlovim strežnikom z zahtevo, da ustvari dogodek z navedenimi podrobnostmi. Nato bi vaš strežnik prejel Googlov odgovor, ga obdelal in brskalniku poslal ustrezne podatke, na primer potrditveno sporočilo uporabniku.

Lahko pa tudi vaš brskalnik pogosto pošlje zahtevo za API neposredno na Googlov strežnik, tako da obide vaš strežnik.

V čem se API tega Google Koledarja razlikuje od API-ja katerega koli drugega oddaljenega strežnika?

V tehničnem smislu je razlika v obliki zahteve in odgovora.

Če želite upodobiti celotno spletno stran, vaš brskalnik pričakuje odgovor v HTML-ju, ki vsebuje predstavitveno kodo, medtem ko bi klic API-ja Google Koledarja samo vrnil podatke - verjetno v obliki, kot je JSON .

Če strežnik vašega spletnega mesta podaja zahtevo za API, potem je strežnik vašega spletnega mesta odjemalec (podobno kot je vaš brskalnik odjemalec, ko ga uporabljate za navigacijo do spletnega mesta).

Z vidika vaših uporabnikov API-ji omogočajo dokončanje dejanja, ne da bi zapustili vaše spletno mesto.

Večina sodobnih spletnih mest uporablja vsaj nekatere API-je tretjih oseb.

Številne težave že imajo neodvisne rešitve, pa naj bo to v obliki knjižnice ali storitve. Uporaba obstoječe rešitve je pogosto preprostejša in zanesljivejša.

Nenavadno je, da razvojne ekipe razdelijo svojo aplikacijo na več strežnikov, ki se med seboj pogovarjajo prek API-jev. Strežniki, ki izvajajo pomožne funkcije za glavni aplikacijski strežnik, se običajno imenujejo mikro storitve .

Če povzamemo, ko podjetje svojim strankam ponudi API, to samo pomeni, da so ustvarili nabor namenskih URL-jev, ki vrnejo čiste podatkovne odzive - kar pomeni, da odgovori ne bodo vsebovali takšnih predstavitvenih stroškov, kot bi jih pričakovali v grafični uporabniški vmesnik, kot je spletno mesto .

Ali lahko te zahteve pošljete z brskalnikom? Pogosto ja. Ker se dejanski prenos HTTP zgodi v besedilu, bo vaš brskalnik vedno po svojih najboljših močeh prikazal odgovor.

Na primer, do GitHub-ovega API-ja lahko dostopate neposredno s svojim brskalnikom, ne da bi potrebovali dostopni žeton. Tu je odgovor JSON, ki ga dobite, ko v brskalniku obiščete pot API-ja uporabnika GitHub (//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"}

Zdi se, da je brskalnik dobro prikazal odziv JSON. Takšen odgovor JSON je pripravljen za uporabo v vaši kodi. Iz tega besedila je enostavno pridobiti podatke. Potem lahko s podatki naredite, kar želite.

A je za "aplikacijo"

Za zaključek naj navedemo še nekaj primerov API-jev.

"Prijava" se lahko nanaša na marsikaj. Nekaj ​​jih je v kontekstu API-ja:

  1. Del programske opreme z ločeno funkcijo.
  2. Celoten strežnik, celotna aplikacija ali le majhen del aplikacije.

V bistvu je vsak del programske opreme, ki ga je mogoče ločiti od svojega okolja, lahko predstavlja "A" v API-ju in verjetno ima tudi nekakšen API.

Recimo, da v svoji kodi uporabljate knjižnico drugega proizvajalca. Ko je knjižnica vključena v kodo, postane del celotne aplikacije. Ker je knjižnica ločen del programske opreme, bi verjetno imela API, ki ji omogoča interakcijo z ostalo kodo.

Tu je še en primer: v objektno usmerjenem oblikovanju je koda organizirana v predmete. Vaša aplikacija ima lahko definiranih na stotine predmetov, ki lahko medsebojno komunicirajo.

Vsak objekt ima API - nabor javnih metod in lastnosti, ki jih uporablja za interakcijo z drugimi predmeti v vaši aplikaciji.

Predmet ima lahko tudi notranjo logiko, ki je zasebna, kar pomeni, da jeskritood zunanjega obsega (in ne API-ja).

Upam, da boste iz tega, kar smo zajeli, odvzeli širši pomen API-ja in današnjo pogostejšo uporabo tega izraza.

Zanimivi viri (stvari, ki sem jih izpustil, a so še vedno zelo kul):

Odličen youtube video o DNS (sistem domenskih imen)

Osnove protokola HTTP

Awesome Khan Academy video o objektno usmerjenih načelih oblikovanja