API står for applikasjonsprogrammeringsgrensesnitt, et konsept som gjelder overalt fra kommandolinjeverktøy til Java-kode til Ruby on Rails webapper. En API er en måte å programmatisk samhandle med en egen programvarekomponent eller ressurs på.
Med mindre du skriver hver eneste linje med kode fra bunnen av, kommer du til å samhandle med eksterne programvarekomponenter, hver med sin egen API. Selv om du skriver noe helt fra bunnen av, vil et godt designet programvare ha interne APIer for å organisere kode og gjøre komponenter mer gjenbrukbare. Og det er mange offentlige APIer som lar deg utnytte funksjonalitet som er utviklet andre steder på nettet.
Hva er et API?
En API er definert som en spesifikasjon av mulige interaksjoner med en programvarekomponent. Hva betyr det egentlig? Tenk deg at en bil var en programvarekomponent. API-en vil inneholde informasjon om hva det kan - akselerere, bremse, slå på radioen osv. Det vil også inneholde informasjon om hvordan du kan få det til å gjøre de tingene. For å akselerere, legger du foten på bensinpedalen og skyver.
API trenger ikke å forklare hva som skjer inne i motoren når du setter foten på gasspedalen. Derfor, hvis du lærte å kjøre bil med forbrenningsmotor, kan du sette deg bak rattet på en elbil uten å måtte lære et helt nytt sett med ferdigheter. De hva og hvordan informasjon samles i API definisjon, som er abstrakt og atskilt fra selve bilen.
En ting å huske på er at navnet på noen API-er ofte brukes til å referere til både spesifikasjonen av interaksjonene og til den faktiske programvarekomponenten du kommuniserer med. Uttrykket "Twitter API", for eksempel, refererer ikke bare til settet med regler for programmatisk samhandling med Twitter, men forstås generelt som det du interagerer med, som i "Vi gjør analyser på tweets vi fikk fra Twitter API. ”
API som abstraksjonslag
Når det gjelder programvare, er API-er bokstavelig talt overalt. APIer går hånd i hånd med et av de mest grunnleggende begrepene innen informatikk: abstraksjon. Abstraksjon er bare en måte å organisere kompleksiteten i et system slik at kompliserte handlinger kan håndteres på en enkel måte. Tenk på denne abstraksjonen som de Amazon Dash-knappene, de batteridrevne trykknappskretsene du kan bruke til å bestille stifter fra Amazon. Slik ser de ut:
Du bestiller en Dash-knapp fra Amazon og bruker en app på smarttelefonen for å knytte den til Wi-Fi-nettverket, Amazon-kontoen din, og et produkt, for eksempel, ditt favorittmerke av papirhåndklær. Så når du vil bestille flere tørkepapir, trykker du bare på knappen. Dash-knappen kobles til Internett og sender en melding for å legge inn en bestilling på kontoen din. Noen dager senere kommer papirhåndklær til døren.
Som en API er Dash-knappen et lykksalig enkelt grensesnitt som skjuler all slags kompleksitet bak kulissene. ID-en for produktet du bestilte, må hentes fra en eller annen database. Leveringsadressen din må hentes fra kontoen din. Det nærmeste oppfyllingssenteret som lager papirhåndklær, må bestemmes og deretter varsles om å fjerne en vare fra den tilgjengelige varen og pakke den opp. Til slutt må pakken rutes gjennom en kombinasjon av fly, lastebiler og varebiler sammen med andre pakker på en måte som sikrer at alle pakkene vil nå sine destinasjoner effektivt.
Tenk deg at du måtte koordinere alle disse tingene som kunde. Du vil aldri bestille papirhåndklær fordi det er for komplisert og tidkrevende, og du har bedre ting å gjøre. Heldigvis blir hele prøvelsen tatt bort fra deg. Det er en lang, sammenkoblet kjede av datasystemer og menneskelige prosesser som gjør at papirhåndklærne dukker opp rett utenfor døren, men alt du trenger å tenke på er å trykke på en knapp.
Slik er API-er for programmerere. De tar en overveldende mengde kompleksitet og definerer et relativt enkelt sett med interaksjoner som du kan bruke i stedet for å gjøre alt selv. I ethvert programvareprosjekt bruker du sannsynligvis titalls om ikke hundrevis av APIer direkte, og hver av disse APIene er avhengige av andre APIer og så videre.
Offentlige APIer og API-integrasjon
APIer er et langvarig konsept innen dataprogrammering, og de har vært en del av utvikleres verktøysett i mange år. Tradisjonelt ble API-er brukt til å koble til kodekomponenter som kjører på samme maskin. Med økningen av allestedsnærværende nettverk, mer og mer offentlige APIer, noen ganger kalt åpne APIer, har blitt tilgjengelig. Offentlige API-er er vendt utover og tilgjengelig via Internett, slik at du kan skrive kode som samhandler med andre leverandørers kode online; denne prosessen er kjent som API-integrasjon.
Denne typen kodemashups tillater brukere å mikse og matche funksjonalitet fra forskjellige leverandører på sine egne systemer. Hvis du for eksempel bruker programvaren for markedsføringsautomatisering Marketo, kan du synkronisere dataene dine der med Salesforce CRM-funksjonalitet.
"Åpen" eller "offentlig" skal ikke tolkes som å være "gratis" i denne sammenheng. Du må fortsatt være Marketo og Salesforce-kunde for at dette skal fungere. Men tilgjengeligheten av disse API-ene gjør integrering til en mye enklere prosess enn den ellers ville vært. ( har en flott liste over offentlige APIer du bør vite om.)
Webtjenester og APIer
Du husker kanskje begrepet web-tjenester fra begynnelsen av 00-tallet og synes at ideen om et åpent API høres ganske likt ut. Faktisk er en nettjeneste en bestemt type åpen API, en som oppfyller et ganske stivt sett med spesifikasjoner, inkludert at de er spesifisert i WSDL (Web Services Description Language), en XML-variant.
Webtjenester var ment å brukes som en del av en serviceorientert arkitektur (SOA). Som den nordiske API-en-bloggen forklarer, ga webtjenestene noe av et dårlig navn, ettersom SOA-er aldri helt levde opp til potensialet. Fremskritt i teknikkene som brukes for kommunikasjon mellom tjenester og tjenester - særlig lettere, mer fleksibel REST - har også etterlatt webtjenester noe etter i verdenen av offentlige APIer.
REST APIer
Webtjenester ble opprinnelig designet for å kommunisere ved hjelp av SOAP (Simple Object Access Protocol), en meldingsprotokoll som sender XML-dokumenter over HTTP. I dag bruker de fleste nettbaserte API-er imidlertid REST — Representational State Transfer — som en arkitektonisk stil.
REST ble formelt introdusert av Roy Fielding i doktorgradsavhandlingen i 2000. Det er et sett med arkitektoniske komponenter, designprinsipper og interaksjoner som brukes til å bygge distribuerte systemer som involverer medier av noe slag (tekst, video osv.). I sin kjerne er REST en stil med bygningssystemer som gir mulighet for fleksibel kommunikasjon og visning av informasjon på nettet, samtidig som den gir struktur som er nødvendig for å enkelt bygge komponenter til generelle formål.
I en REST API, a ressurs kan være stort sett hva som helst, men eksempler inkluderer en bruker, en liste over tweets og de nåværende resultatene av et søk etter tweets. Hver av disse ressursene kan adresseres til a ressursidentifikator, som når det gjelder nettbaserte REST APIer, vanligvis er en URL, for eksempel //api.twitter.com/1.1/users/show?screen_name=twitterdev. Når et program ber om en ressurs ved hjelp av identifikatoren, leverer API-en strømmen representasjon av den ressursen til applikasjonen i et format som applikasjonen kan konsumere, for eksempel et JPEG-bilde, HTML-side eller JSON.
En av de store forskjellene til REST er at det innebærer å sende data til den anmodende applikasjonen. Selv om dette gir stor fleksibilitet, slik at applikasjonen kan gjøre hva den vil med dataene, koster det effektiviteten. Det er ganske tregt å sende data over nettet for behandling sammenlignet med å utføre behandlingen der dataene ligger og deretter sende resultatene.
Selvfølgelig er problemet med den "effektive" tilnærmingen at systemer som er vert for dataene, trenger å vite hva applikasjoner vil gjøre med det på forhånd. For å bygge et API som har generell brukervennlighet og fleksibilitet, er REST veien å gå.
API eksempler
Det er mange offentlige APIer der ute for å samhandle med, mange fra bransjekonkurranser. Evnen til å få tilgang til noe plattformsselskaps kode programmatisk via en API er det som gjør dem til en plattform. Noen fremtredende API-eksempler inkluderer:
- Google API-er, som lar deg koble koden din til hele spekteret av Google-tjenester, fra Maps til Translate. APIer er så viktige for Google at de kjøpte Apigee, en ledende API-administrasjonsplattform.
- Facebook-APIer, som lar deg programmatisk få tilgang til Facebooks sosiale graf og markedsføringsverktøy. (Selskapet har begrenset akkurat hvilke brukerdata du har tilgang til via disse API-ene i nedfallet fra Cambridge Analytica og andre skandaler.)
For å virkelig få en følelse av hvordan API-er fungerer, la oss gjøre et dypdykk i to: Java API, som Java-utviklere bruker til å samhandle med Java-plattformen, og Twitter API, en offentlig API som du vil bruke til å samhandle med det sosiale nettverkstjeneste.
Java API
Java API er et bibliotek med programvarekomponenter som er tilgjengelige "ut av esken" for alle som har installert Java Development Kit. Disse komponentene implementerer vanlige oppgaver og øker generelt produktiviteten fordi programmerere ikke trenger å starte fra bunnen av hver gang. En av de grunnleggende komponentene som brukes i programvare er noe som kalles en liste, som, som du kanskje forventer, holder oversikt over en liste over elementer. Java API definerer hva du kan gjøre med en liste: legge til elementer, sortere listen, bestemme om et element er i listen osv. Det spesifiseres også hvordan å utføre disse handlingene. For å kunne sortere listen, må du spesifisere hvordan du vil at listen skal sorteres: alfabetisk, numerisk synkende, lyseste til matteste farge osv.
Twitter API
Twitter API er et nettbasert JSON API som lar utviklere programmatisk samhandle med Twitter-data. I motsetning til Java API, som er inkludert i Java Development Kit, er Twitter API et nettbasert API. Det må nås ved å sende forespørsler over Internett til tjenester som Twitter er vert for.
Med et nettbasert API som Twitter, sender applikasjonen din en HTTP-forespørsel, akkurat som en nettleser gjør. Men i stedet for at svaret blir levert som en webside, for menneskelig forståelse, returneres det i et format som applikasjoner enkelt kan analysere. Ulike formater eksisterer for dette formålet, og Twitter bruker et populært og brukervennlig format kalt JSON. (Hvis du ikke er kjent med JSON, kan det være lurt å bruke noen minutter på å lese opp det her.)
Et av de grunnleggende elementene i Twitter er en tweet. Twitter API forteller deg hva du kan gjøre med tweets: søk etter tweets, opprett en tweet, favoritt en tweet. Det forteller deg også hvordan for å utføre disse handlingene. For å søke etter tweets, må du spesifisere søkekriteriene: termer eller hashtags å se etter, geolokalisering, språk osv.
API-design
API-design er prosessen der "hva" og "hvordan" til en API formuleres. Som med alt annet som kan opprettes, legges ulike nivåer av tanke og omsorg i API-design, noe som resulterer i varierende nivåer av API-kvalitet. Godt utformede API-er har jevn oppførsel, tar hensyn til deres kontekst og husker brukernes behov.
Konsistent oppførsel i en API påvirker i stor grad hastigheten den kan læres på og sannsynligheten for at programmerere gjør feil når de bruker den. Vanligvis skal API-er som utfører lignende handlinger oppføre seg likt, uavhengig av tekniske forskjeller. For et eksempel på et inkonsekvent API, la oss se på de to måtene å legge til et element i en liste i Java:
Selv om de to metodene for å legge til ting på en liste, gjør det samme, er returtypene (boolske og ugyldige) forskjellige. Utviklere som bruker denne API-en, må nå holde rede på hvilken metode som returnerer hvilken type, noe som gjør API-en vanskeligere å lære og bruken er mer utsatt for feil. Det betyr også at koden som bruker disse metodene blir mindre fleksibel, fordi den må endres hvis du vil endre måten du legger til elementer på.
Å ta hensyn til kontekst er en annen form for konsistens, selv om det har å gjøre med faktorer utenfor API. Et flott, ikke-programvareeksempel på dette er hvordan veiregelen - høyre eller venstrekjøring - påvirker bildesign for forskjellige land. Bildesignere tar den miljøfaktoren i betraktning når de finner førersetet på høyre eller venstre side av bilen.
