Prije nego što sam naučio razvoj softvera, API je zvučao kao neka vrsta piva.
Danas taj izraz koristim toliko često da sam zapravo nedavno pokušao naručiti API u baru.
Barmenov odgovor bio je baciti 404: resurs nije pronađen.
Upoznajem puno ljudi, kako onih koji rade u tehnici, tako i drugdje, koji imaju prilično maglovitu ili netočnu predodžbu o tome što znači ovaj prilično uobičajeni izraz.
Tehnički, API je skraćenica od Application Programming Sučelje . U nekom trenutku, većina velikih tvrtki izgradila je API-je za svoje kupce ili za internu upotrebu.
Ali kako objasniti API na običnom engleskom? A postoji li šire značenje od onog koje se koristi u razvoju i poslovanju? Prvo se povucimo i pogledajmo kako sam web funkcionira.
WWW i udaljeni poslužitelji
Kad razmišljam o Webu, zamišljam veliku mrežu povezanih poslužitelja.
Svaka stranica na Internetu pohranjena je negdje na udaljenom poslužitelju. Udaljeni poslužitelj ipak nije toliko mističan - to je samo dio udaljenog računala koje je optimizirano za obradu zahtjeva.
Da biste stvari stavili u perspektivu, na svom prijenosnom računalu možete okretati poslužitelj koji može opsluživati cijelo web mjesto (zapravo, lokalni poslužitelj je ono što inženjeri koriste za izradu web stranica prije nego što ih puste u javnost).
Kad u svoj preglednik upišete www.facebook.com, zahtjev se šalje na udaljeni Facebook poslužitelj. Nakon što vaš preglednik primi odgovor, on interpretira kôd i prikazuje stranicu.
Za preglednik, poznat i kao klijent , Facebook poslužitelj je API. To znači da svaki put kada posjetite stranicu na Webu, komunicirate s API-jem udaljenog poslužitelja.
API nije isto što i udaljeni poslužitelj - već je to dio poslužitelja koji prima zahtjeve i šalje odgovore .
API-ji kao način da uslužite svoje kupce
Vjerojatno ste čuli za tvrtke koje API-je pakiraju kao proizvode. Na primjer, Weather Underground prodaje pristup svom API-ju za vremenske podatke.
Primjer scenarija: Web mjesto vaše male tvrtke ima obrazac koji se koristi za prijavu klijenata na sastanke. Svojim klijentima želite pružiti mogućnost da automatski stvore događaj Google kalendara s pojedinostima za taj sastanak.
Upotreba API-ja: Ideja je da poslužitelj vaše web stranice razgovara izravno s Googleovim poslužiteljem sa zahtjevom za stvaranje događaja s danim detaljima. Vaš će poslužitelj tada primiti Googleov odgovor, obraditi ga i poslati natrag relevantne informacije u preglednik, poput poruke o potvrdi korisniku.
Alternativno, vaš preglednik često može poslati API zahtjev izravno na Googleov poslužitelj zaobilazeći vaš poslužitelj.
Po čemu se API ovog kalendara razlikuje od API-ja bilo kojeg drugog udaljenog poslužitelja?
U tehničkom smislu , razlika je u formatu zahtjeva i odgovora.
Da bi prikazao cijelu web stranicu, vaš preglednik očekuje odgovor u HTML-u koji sadrži prezentacijski kôd, dok bi API poziv Google kalendara samo vratio podatke - vjerojatno u formatu poput JSON-a .
Ako poslužitelj vašeg web mjesta izrađuje API zahtjev, tada je poslužitelj vašeg web mjesta klijent (slično kao što je vaš preglednik klijent kada ga koristite za navigaciju do web mjesta).
Iz perspektive vaših korisnika, API-ji im omogućavaju da dovrše radnju bez napuštanja vaše web stranice.
Većina modernih web stranica troši barem neke API-je treće strane.
Mnogi problemi već imaju rješenje treće strane, bilo u obliku knjižnice ili usluge. Često je jednostavno i pouzdanije koristiti postojeće rješenje.
Nerijetko je da razvojni timovi razbiju svoju aplikaciju na više poslužitelja koji međusobno razgovaraju putem API-ja. Poslužitelji koji izvode pomoćne funkcije za glavni aplikacijski poslužitelj obično se nazivaju mikrouslugama .
Da rezimiramo, kada tvrtka nudi API svojim kupcima, to samo znači da su izgradili skup namjenskih URL-ova koji vraćaju čiste odgovore podataka - što znači da odgovori neće sadržavati vrstu prezentacijskih troškova koje biste očekivali u grafičko korisničko sučelje poput web mjesta .
Možete li uputiti ove zahtjeve putem preglednika? Često, da. Budući da se stvarni HTTP prijenos događa u tekstu, vaš će preglednik uvijek učiniti najbolje što može da prikaže odgovor.
Na primjer, API-ju GitHub možete pristupiti izravno putem preglednika, čak i bez potrebe za pristupnim tokenom. Evo JSON odgovora koji dobijete kada posjetite API put korisnika GitHub u vašem pregledniku (//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"}Čini se da je preglednik izvrsno prikazao JSON odgovor. Ovakav JSON odgovor spreman je za upotrebu u vašem kodu. Iz ovog je teksta lako izvući podatke. Tada s podacima možete raditi što god želite.
A je za "prijavu"
Da zatvorimo, ubacimo još nekoliko primjera API-ja.
"Prijava" se može odnositi na mnoge stvari. Evo nekih od njih u kontekstu API-ja:
- Komad softvera s posebnom funkcijom.
- Cijeli poslužitelj, cijela aplikacija ili samo mali dio aplikacije.
U osnovi bilo koji softver koji se može zasebno odvojiti od svog okruženja, može biti "A" u API-ju i vjerojatno će imati i nekakav API.
Recimo da u kodu upotrebljavate biblioteku treće strane. Jednom ugrađena u vaš kôd, knjižnica postaje dio vaše cjelokupne aplikacije. Budući da je zaseban softver, knjižnica bi vjerojatno imala API koji joj omogućuje interakciju s ostatkom vašeg koda.
Evo još jednog primjera: U objektno orijentiranom dizajnu kôd je organiziran u objekte. Vaša aplikacija može imati definirane stotine objekata koji mogu međusobno komunicirati.
Svaki objekt ima API - skup javnih metoda i svojstava koje koristi za interakciju s drugim objektima u vašoj aplikaciji.
Predmet može imati i unutarnju logiku koja je privatna, što znači da jestskriveniz vanjskog opsega (a ne API-ja).
Iz onoga što smo pokrili, nadam se da ćete ukloniti šire značenje API-ja kao i uobičajenu upotrebu pojma danas.
Zanimljivi resursi (stvari koje sam izostavio, ali su i dalje jako cool):
Sjajan youtube video o DNS-u (sustav imena domena)
Osnove HTTP protokola
Awesome Khan Academy video o objektno orijentiranim principima dizajna