Hvad er en API? På engelsk tak.

Før jeg lærte softwareudvikling, lød API som en slags øl.

I dag bruger jeg udtrykket så ofte, at jeg faktisk for nylig har forsøgt at bestille en API på en bar.

Bartenderens svar var at smide en 404: ressource ikke fundet.

Jeg møder mange mennesker, der begge arbejder inden for teknologi og andre steder, som har en temmelig vag eller forkert idé om, hvad dette ret almindelige udtryk betyder.

Teknisk set står API for Application Programming Interface . På et eller andet tidspunkt har de fleste store virksomheder bygget API'er til deres kunder eller til intern brug.

Men hvordan forklarer du API på almindelig engelsk? Og er der en bredere betydning end den, der bruges i udvikling og forretning? Lad os først trække os tilbage og se på, hvordan selve internettet fungerer.

WWW og eksterne servere

Når jeg tænker på Internettet, forestiller jeg mig et stort netværk af tilsluttede servere.

Hver side på internettet er gemt et eller andet sted på en ekstern server. En fjernserver er trods alt ikke så mystisk - det er bare en del af en eksternt placeret computer, der er optimeret til at behandle anmodninger.

For at sætte tingene i perspektiv kan du spinde en server på din bærbare computer, der er i stand til at betjene et helt websted på Internettet (faktisk er en lokal server, hvad ingeniører bruger til at udvikle websteder, før de frigiver dem til offentligheden).

Når du skriver www.facebook.com i din browser, går en anmodning ud til Facebooks fjernserver. Når din browser modtager svaret, fortolker den koden og viser siden.

For browseren, også kendt som klienten , er Facebooks server en API. Dette betyder, at hver gang du besøger en side på Internettet, interagerer du med en fjernserver's API.

En API er ikke den samme som den eksterne server - det er snarere den del af serveren, der modtager anmodninger og sender svar .

API'er som en måde at betjene dine kunder på

Du har sikkert hørt om virksomheder, der emballerer API'er som produkter. For eksempel sælger Weather Underground adgang til sin API for vejrdata.

Eksempel på scenarie: Din lille virksomheds hjemmeside har en formular, der bruges til at tilmelde kunder til aftaler. Du vil give dine klienter mulighed for automatisk at oprette en Google-kalenderbegivenhed med detaljerne til den aftale.

API-brug: Ideen er at få dit websteds server til at tale direkte med Googles server med en anmodning om at oprette en begivenhed med de givne detaljer. Din server modtager derefter Googles svar, behandler det og sender relevante oplysninger tilbage til browseren, såsom en bekræftelsesmeddelelse til brugeren.

Alternativt kan din browser ofte sende en API-anmodning direkte til Googles server uden om din server.

Hvordan adskiller denne Google Kalenders API sig fra API'en på enhver anden fjernserver derude?

I tekniske termer er forskellen formatet på anmodningen og svaret.

For at gengive hele websiden forventer din browser et svar i HTML, der indeholder præsentationskode, mens Google Kalenders API-opkald bare returnerer dataene - sandsynligvis i et format som JSON .

Hvis dit websteds server fremsætter API-anmodning, er dit websides server klienten (svarende til at din browser er klienten, når du bruger den til at navigere til et websted).

Fra dine brugerperspektiv tillader API'er dem at fuldføre handlingen uden at forlade dit websted.

De fleste moderne websteder bruger mindst nogle tredjeparts-API'er.

Mange problemer har allerede en tredjepartsløsning, det være sig i form af et bibliotek eller en tjeneste. Det er ofte bare nemmere og mere pålideligt at bruge en eksisterende løsning.

Det er ikke ualmindeligt, at udviklingsteam opdeler deres applikation i flere servere, der taler med hinanden via API'er. Serverne, der udfører hjælpefunktioner til den primære applikationsserver, kaldes ofte mikroservices .

For at opsummere, når en virksomhed tilbyder en API til deres kunder, betyder det bare, at de har bygget et sæt dedikerede URL'er, der returnerer rene datasvar - hvilket betyder, at svarene ikke indeholder den slags præsentationsomkostninger, som du ville forvente i en grafisk brugergrænseflade som et websted .

Kan du fremsætte disse anmodninger med din browser? Ofte ja. Da den faktiske HTTP-transmission sker i tekst, vil din browser altid gøre det bedste for at vise svaret.

For eksempel kan du få adgang til GitHubs API direkte med din browser uden engang at have brug for et adgangstoken. Her er JSON-svaret, du får, når du besøger en GitHub-brugers API-rute i din browser (//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"}

Browseren ser ud til at have gjort det fint at vise et JSON-svar. Et JSON-svar som dette er klar til brug i din kode. Det er let at udtrække data fra denne tekst. Derefter kan du gøre hvad du vil med dataene.

A er til "Application"

Lad os afslutte et par flere eksempler på API'er for at lukke.

"Applikation" kan henvise til mange ting. Her er nogle af dem i forbindelse med API:

  1. Et stykke software med en særskilt funktion.
  2. Hele serveren, hele appen eller bare en lille del af en app.

Dybest set kan ethvert stykke software, der kan adskilles særskilt fra sit miljø, være et “A” i API og vil sandsynligvis også have en slags API.

Lad os sige, at du bruger et tredjepartsbibliotek i din kode. Når det er indarbejdet i din kode, bliver et bibliotek en del af din samlede app. At være et særskilt stykke software, ville biblioteket sandsynligvis have en API, der gør det muligt at interagere med resten af ​​din kode.

Her er et andet eksempel: I objektorienteret design er kode organiseret i objekter. Din applikation kan have defineret hundredvis af objekter, der kan interagere med hinanden.

Hvert objekt har en API - et sæt offentlige metoder og egenskaber, som det bruger til at interagere med andre objekter i din applikation.

Et objekt kan også have indre logik, der er privat, hvilket betyder, at det erskjultfra det ydre anvendelsesområde (og ikke en API).

Fra det, vi har dækket, håber jeg, at du fjerner den bredere betydning af API såvel som de mere almindelige anvendelser af udtrykket i dag.

Interessante ressourcer (ting, som jeg har udeladt, men stadig er meget sejt):

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

Grundlæggende om HTTP-protokol

En fantastisk Khan Academy-video om objektorienterede designprincipper