Kas ir API? Angliski, lūdzu.

Pirms es uzzināju programmatūras izstrādi, API izklausījās pēc sava veida alus.

Šodien es tik bieži lietoju šo terminu, ka patiesībā nesen mēģināju bārā pasūtīt API.

Bārmeņa atbilde bija iemest 404: resurss nav atrasts.

Es satieku daudz cilvēku, kas strādā gan tehnikā, gan citur, kuriem ir diezgan neskaidrs vai nepareizs priekšstats par to, ko nozīmē šis diezgan izplatītais termins.

Tehniski API nozīmē lietojumprogrammu saskarni . Vienā vai otrā brīdī lielākā daļa lielo uzņēmumu ir izveidojuši API klientiem vai iekšējai lietošanai.

Bet kā jūs vienkāršā angļu valodā izskaidrojat API? Un vai ir plašāka nozīme nekā tā, ko izmanto attīstībā un biznesā? Pirmkārt, pievērsīsimies un apskatīsim, kā darbojas pats tīmeklis.

WWW un attālie serveri

Domājot par tīmekli, es iedomājos lielu pievienotu serveru tīklu .

Katra lappuse internetā tiek glabāta kaut kur uz attālā servera. Attālais serveris galu galā nav tik mistisks - tas ir tikai attālināti atrodama datora daļa, kas ir optimizēta pieprasījumu apstrādei.

Lai lietas skatītu perspektīvā, varat savā klēpjdatorā izveidot serveri, kas spēj tīmeklī apkalpot visu vietni (faktiski vietējais serveris ir tas, ko inženieri izmanto vietņu izstrādei, pirms tās izlaiž sabiedrībai).

Kad pārlūkprogrammā ierakstāt www.facebook.com, pieprasījums tiek nosūtīts uz Facebook attālo serveri. Kad jūsu pārlūkprogramma saņem atbildi, tā interpretē kodu un parāda lapu.

Pārlūkprogrammai, kas pazīstama arī kā klients , Facebook serveris ir API. Tas nozīmē, ka katru reizi, kad apmeklējat tīmekļa lapu, jūs mijiedarbojaties ar kāda attālā servera API.

API nav tas pats, kas attālais serveris - drīzāk tā ir tā servera daļa, kas saņem pieprasījumus un nosūta atbildes .

API kā veids, kā apkalpot savus klientus

Jūs, iespējams, esat dzirdējuši par uzņēmumiem, kas iepako API kā produktus. Piemēram, Weather Underground pārdod piekļuvi laika apstākļu datu API.

Scenārija piemērs: Jūsu mazā uzņēmuma vietnē ir veidlapa, ko izmanto, lai pierakstītos klientiem uz tikšanos. Jūs vēlaties dot saviem klientiem iespēju automātiski izveidot Google kalendāra notikumu ar detalizētu informāciju par šo tikšanos.

API izmantošana: ideja ir panākt, lai jūsu vietnes serveris runātu tieši ar Google serveri ar lūgumu izveidot notikumu ar norādīto informāciju. Jūsu serveris pēc tam saņemtu Google atbildi, to apstrādātu un pārlūkprogrammai nosūtītu atpakaļ atbilstošu informāciju, piemēram, apstiprinājuma ziņojumu lietotājam.

Alternatīvi, jūsu pārlūkprogramma bieži var nosūtīt API pieprasījumu tieši uz Google serveri, apejot jūsu serveri.

Kā šī Google kalendāra API atšķiras no jebkura cita attālā servera API?

Tehniskā ziņā atšķirība ir pieprasījuma un atbildes formāts.

Lai renderētu visu tīmekļa lapu, jūsu pārlūkprogramma sagaida atbildi HTML formātā, kas satur prezentācijas kodu, savukārt Google kalendāra API zvans vienkārši atgriezīs datus - iespējams, tādā formātā kā JSON .

Ja jūsu vietnes serveris iesniedz API pieprasījumu, tad jūsu vietnes serveris ir klients (līdzīgi kā jūsu pārlūkprogramma ir klients, kad to izmantojat, lai virzītos uz vietni).

No jūsu lietotāju viedokļa API ļauj viņiem pabeigt darbību, neatstājot jūsu vietni.

Lielākā daļa mūsdienu vietņu patērē vismaz dažas trešo pušu API.

Daudzām problēmām jau ir trešās puses risinājums, vai tas būtu bibliotēkas vai pakalpojuma veidā. Bieži vien esošā risinājuma izmantošana ir vienkārši vienkāršāka un uzticamāka.

Nav nekas neparasts, ka izstrādātāju komandas savu lietojumu sadala vairākos serveros, kas savā starpā runā, izmantojot API. Serveri, kas veic palīgfunkcijas galvenajam lietojumprogrammu serverim, parasti tiek saukti par mikropakalpojumiem .

Rezumējot, ja uzņēmums saviem klientiem piedāvā API, tas vienkārši nozīmē, ka viņi ir izveidojuši īpašu URL kopu, kas atgriež tīras datu atbildes - tas nozīmē, ka atbildēs nebūs tādas prezentācijas pieskaitāmās izmaksas, kādas varētu sagaidīt grafiskā lietotāja saskarne, piemēram, vietne .

Vai jūs varat iesniegt šos pieprasījumus savā pārlūkprogrammā? Bieži, jā. Tā kā faktiskā HTTP pārraide notiek tekstā, jūsu pārlūkprogramma vienmēr darīs visu iespējamo, lai parādītu atbildi.

Piemēram, jūs varat piekļūt GitHub API tieši ar savu pārlūkprogrammu, pat neprasot piekļuves pilnvaru. Lūk, JSON atbilde, ko saņemat, apmeklējot GitHub lietotāja API maršrutu savā pārlūkprogrammā (//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"}

Šķiet, ka pārlūks ir paveicis lieliski, parādot JSON atbildi. Šāda JSON atbilde ir gatava lietošanai jūsu kodā. No šī teksta ir viegli iegūt datus. Tad jūs varat darīt visu, ko vēlaties, izmantojot datus.

A ir paredzēts lietojumprogrammai

Lai beigtu darbu, iemetīsim vēl pāris API piemērus.

“Pieteikums” var atsaukties uz daudzām lietām. Šeit ir daži no tiem API kontekstā:

  1. Programmatūras gabals ar atšķirīgu funkciju.
  2. Viss serveris, visa lietotne vai tikai neliela lietotnes daļa.

Būtībā jebkura programmatūras daļa, kuru var skaidri nošķirt no tās vides, var būt “A” API un, iespējams, tai būs arī sava veida API.

Pieņemsim, ka savā kodā izmantojat trešās puses bibliotēku. Kad bibliotēka būs iekļauta jūsu kodā, tā kļūs par jūsu lietotnes daļu. Tā kā bibliotēka ir atsevišķa programmatūras daļa, visticamāk, tai ir API, kas ļauj tai mijiedarboties ar pārējo jūsu kodu.

Lūk, vēl viens piemērs: Objektorientētā dizainā kods tiek organizēts objektos. Jūsu lietojumprogrammā var būt definēti simtiem objektu, kas var savstarpēji mijiedarboties.

Katram objektam ir API - publisku metožu un rekvizītu kopa, ko tā izmanto, lai mijiedarbotos ar citiem jūsu lietojumprogrammas objektiem.

Objektam var būt arī privāta iekšējā loģika, kas nozīmē, ka tas irpaslēptsno ārpuses (un ne API).

No tā, ko mēs esam aprakstījuši, es ceru, ka jūs atņemsit API plašāku nozīmi, kā arī šī vārda biežākos lietojumus šodien.

Interesanti resursi (sīkumi, kurus es izlaidu, bet joprojām esmu ļoti foršs):

Lielisks YouTube video DNS (domēna vārdu sistēmā)

HTTP protokola pamati

Awesome Khan Academy video par objektorientēta dizaina principiem