Hva er et API? På Engelsk vær så snill.

Før jeg lærte programvareutvikling, hørtes API ut som en slags øl.

I dag bruker jeg begrepet så ofte at jeg faktisk nylig har prøvd å bestille en API på en bar.

Bartenderens svar var å kaste en 404: ressurs ikke funnet.

Jeg møter mange mennesker, begge som jobber innen teknologi og andre steder, som har en ganske vag eller feil ide om hva dette ganske vanlige begrepet betyr.

Teknisk sett står API for Application Programming Interface . På et eller annet tidspunkt har de fleste store selskaper bygget API-er for sine kunder, eller for internt bruk.

Men hvordan forklarer du API på vanlig engelsk? Og er det en bredere betydning enn den som brukes i utvikling og næringsliv? La oss først trekke oss tilbake og se på hvordan nettet fungerer.

WWW og eksterne servere

Når jeg tenker på nettet, forestiller jeg meg et stort nettverk av tilkoblede servere.

Hver side på internett lagres et sted på en ekstern server. En ekstern server er tross alt ikke så mystisk - det er bare en del av en eksternt lokalisert datamaskin som er optimalisert for å behandle forespørsler.

For å sette ting i perspektiv kan du spinne opp en server på den bærbare datamaskinen som kan betjene et helt nettsted på nettet (faktisk er en lokal server det ingeniører bruker for å utvikle nettsteder før de slipper dem til publikum).

Når du skriver inn www.facebook.com i nettleseren din, går en forespørsel til Facebooks eksterne server. Når nettleseren din mottar svaret, tolker den koden og viser siden.

For nettleseren, også kjent som klienten , er Facebooks server en API. Dette betyr at hver gang du besøker en side på nettet, samhandler du med API-en til noen eksterne servere.

Et API er ikke det samme som den eksterne serveren - det er heller den delen av serveren som mottar forespørsler og sender svar .

APIer som en måte å betjene kundene dine på

Du har sikkert hørt om selskaper som pakker APIer som produkter. For eksempel selger Weather Underground tilgang til API'en for værdata.

Eksempel på scenario: Din lille virksomhets nettsted har et skjema som brukes til å registrere kunder for avtaler. Du vil gi kundene dine muligheten til automatisk å opprette en Google-kalenderhendelse med detaljene for den avtalen.

API-bruk: Tanken er å få nettstedets server til å snakke direkte med Googles server med en forespørsel om å lage en hendelse med de gitte detaljene. Serveren din vil da motta Googles svar, behandle det og sende relevant informasjon tilbake til nettleseren, for eksempel en bekreftelsesmelding til brukeren.

Alternativt kan nettleseren din ofte sende en API-forespørsel direkte til Googles server utenom serveren din.

Hvordan er denne Google Kalender-APIen forskjellig fra API-en til en annen ekstern server der ute?

I tekniske termer er forskjellen formatet på forespørselen og svaret.

For å gjengi hele websiden forventer nettleseren din et svar i HTML, som inneholder presentasjonskode, mens Google Kalenders API-anrop bare vil returnere dataene - sannsynligvis i et format som JSON .

Hvis nettstedet ditt serverer API-forespørsel, er nettstedets server klienten (i likhet med at nettleseren din er klienten når du bruker den til å navigere til et nettsted).

Fra brukernes perspektiv tillater APIer dem å fullføre handlingen uten å forlate nettstedet ditt.

De fleste moderne nettsteder bruker minst noen tredjeparts APIer.

Mange problemer har allerede en tredjepartsløsning, det være seg i form av et bibliotek eller en tjeneste. Det er ofte bare enklere og mer pålitelig å bruke en eksisterende løsning.

Det er ikke uvanlig at utviklingsteam deler opp søknaden i flere servere som snakker med hverandre via API-er. Serverne som utfører hjelperfunksjoner for hovedapplikasjonsserveren, kalles ofte mikrotjenester .

For å oppsummere, når et selskap tilbyr et API til kundene sine, betyr det bare at de har laget et sett med dedikerte nettadresser som returnerer rene datasvar - noe som betyr at svarene ikke inneholder den typen presentasjonsomkostninger du forventer i en grafisk brukergrensesnitt som et nettsted .

Kan du komme med disse forespørslene i nettleseren din? Ofte, ja. Siden den faktiske HTTP-overføringen skjer i tekst, vil nettleseren din alltid gjøre så godt den kan for å vise svaret.

For eksempel kan du få tilgang til GitHubs API direkte med nettleseren din uten at du trenger et tilgangstoken. Her er JSON-svaret du får når du besøker en GitHub-brukerens API-rute i nettleseren din (//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"}

Nettleseren ser ut til å ha gjort det bra å vise et JSON-svar. Et JSON-svar som dette er klart til bruk i koden din. Det er enkelt å hente ut data fra denne teksten. Da kan du gjøre hva du vil med dataene.

A er for “Application”

For å avslutte, la oss kaste inn et par eksempler på APIer.

"Søknad" kan referere til mange ting. Her er noen av dem i sammenheng med API:

  1. Et stykke programvare med en distinkt funksjon.
  2. Hele serveren, hele appen eller bare en liten del av en app.

I utgangspunktet kan en hvilken som helst programvare som kan skilles adskilt fra omgivelsene, være et "A" i API, og vil trolig også ha en slags API.

La oss si at du bruker et tredjepartsbibliotek i koden din. Når det er innlemmet i koden din, blir et bibliotek en del av den generelle appen din. Å være et tydelig programvare, vil biblioteket sannsynligvis ha et API som gjør det mulig å samhandle med resten av koden din.

Her er et annet eksempel: I objektorientert design er koden organisert i objekter. Søknaden din kan ha hundrevis av objekter definert som kan samhandle med hverandre.

Hvert objekt har en API - et sett med offentlige metoder og egenskaper som det bruker til å samhandle med andre objekter i applikasjonen din.

Et objekt kan også ha indre logikk som er privat, noe som betyr at det erskjultfra utenforområdet (og ikke en API).

Fra det vi har dekket, håper jeg du tar bort den bredere betydningen av API, så vel som de mer vanlige bruken av begrepet i dag.

Interessante ressurser (ting som jeg har utelatt, men som fortsatt er veldig kult):

En flott youtube-video på DNS ​​(Domain Name System)

Grunnleggende om HTTP-protokoll

En fantastisk Khan Academy-video om objektorienterte designprinsipper