Vad är ett API? Gränssnitt för applikationsprogrammering förklaras

API står för applikationsprogrammeringsgränssnitt, ett koncept som gäller överallt, från kommandoradsverktyg till företagets Java-kod till Ruby on Rails webbappar. Ett API är ett sätt att programmatiskt interagera med en separat programvarukomponent eller resurs.

Om du inte skriver varje rad kod från början kommer du att interagera med externa programvarukomponenter, var och en med sitt eget API. Även om du skriver något helt från grunden kommer en väldesignad programvara att ha interna API: er som hjälper till att organisera kod och göra komponenter mer återanvändbara. Och det finns många offentliga API: er som låter dig utnyttja funktionalitet som utvecklats någon annanstans på nätet.

Vad är ett API?

Ett API definieras som en specifikation av möjliga interaktioner med en programvarukomponent. Vad betyder det exakt? Tänk dig att en bil var en programvarukomponent. Dess API skulle innehålla information om vad den kan göra - påskynda, bromsa, sätta på radion osv. Det skulle också innehålla information om hur du kan få den att göra dessa saker. Till exempel, för att accelerera, sätter du foten på gaspedalen och trycker på.

API: t behöver inte förklara vad som händer inuti motorn när du sätter foten på gaspedalen. Det är därför, om du lärde dig att köra bil med förbränningsmotor kan du sätta dig bakom ratten i en elbil utan att behöva lära dig en helt ny uppsättning färdigheter. Den vad och hur informationen samlas i API definition , som är abstrakt och separat från själva bilen.

En sak att tänka på är att namnet på vissa API: er ofta används för att hänvisa till både specifikationen av interaktionerna och till den faktiska programvarukomponenten du interagerar med. Uttrycket "Twitter API", till exempel, hänvisar inte bara till uppsättningen regler för programmatisk interaktion med Twitter, men förstås i allmänhet det som du interagerar med, som i "Vi gör analyser på tweets vi fick från Twitter API. ”

API som abstraktionsskikt

När det gäller programvara finns API: er bokstavligen överallt. API: er går hand i hand med ett av de mest grundläggande begreppen inom datavetenskap: abstraktion. Abstraktion är bara ett sätt att organisera komplexiteten i ett system så att komplicerade åtgärder kan hanteras på ett enkelt sätt. Tänk på denna abstraktion som de Amazon Dash-knapparna, de batteridrivna tryckknappskretsarna som du kan använda för att beställa häftklamrar från Amazon. Så här ser de ut:

Du beställer en Dash-knapp från Amazon och använder en app på din smartphone för att koppla den till ditt Wi-Fi-nätverk, ditt Amazon-konto och en produkt, säg, ditt favoritmärke av pappershanddukar. Sedan, när du vill beställa fler pappershanddukar, trycker du bara på knappen. Dash-knappen ansluter till Internet och skickar ett meddelande för att göra en beställning på ditt konto. Några dagar senare kommer pappershanddukar till din tröskel.

Som ett API är Dash-knappen ett lyckligt enkelt gränssnitt som döljer all slags komplexitet bakom kulisserna. ID för den produkt du beställde måste hämtas från någon databas. Din leveransadress måste hämtas från ditt konto. Det närmaste upphandlingscentret med dina pappershanddukar måste fastställas och sedan meddelas för att ta bort en vara från det tillgängliga lagret och packa upp den. Slutligen måste paketet dirigeras genom någon kombination av flygplan, lastbilar och skåpbilar tillsammans med andra paket på ett sätt som säkerställer att alla paket når sina destinationer effektivt.

Tänk dig nu att du var tvungen att samordna alla dessa saker som kund. Du skulle aldrig beställa pappershanddukar eftersom det är för komplicerat och tidskrävande och du har bättre saker att göra. Lyckligtvis är hela prövningen abstraherad från dig. Det finns en lång, sammankopplad kedja av datorsystem och mänskliga processer som gör att dessa pappershanddukar dyker upp vid din tröskel, men allt du behöver tänka på är att trycka på en knapp.

Så här är API: er för programmerare. De tar en överväldigande mängd komplexitet och definierar en relativt enkel uppsättning interaktioner som du kan använda istället för att göra allt själv. I alla programvaruprojekt använder du sannolikt tiotals om inte hundratals API: er direkt, och var och en av dessa API: er är beroende av andra API: er och så vidare.

Offentliga API: er och API-integration

API: er är ett långvarigt koncept inom datorprogrammering och de har varit en del av utvecklarnas verktygssatser i flera år. Traditionellt användes API: er för att ansluta kodkomponenter som körs på samma maskin. Med ökningen av allestädes närvarande nätverk har fler och fler offentliga API: er, ibland kallat öppna API: er, blivit tillgängliga. Offentliga API: er är utåtvända och tillgängliga via Internet, så att du kan skriva kod som interagerar med andra leverantörskoder online; denna process kallas API-integration.

Dessa typer av kodmashups tillåter användare att mixa och matcha funktionalitet från olika leverantörer på sina egna system. Om du till exempel använder programvaran för marknadsföringsautomation Marketo kan du synkronisera dina data där med Salesforce CRM-funktionalitet.

"Öppet" eller "offentligt" ska inte tolkas som att det betyder "gratis" i detta sammanhang. Du måste fortfarande vara Marketo- och Salesforce-kund för att detta ska fungera. Men tillgången på dessa API: er gör integrationen till en mycket enklare process än den annars skulle vara. ( har en bra lista över offentliga API: er du borde veta om.)

Webbtjänster och API: er

Du kommer kanske ihåg termen w eb-tjänster från början av 00-talet och tycker att idén om ett öppet API låter ganska lika. I själva verket är en webbtjänst en specifik typ av öppet API, en som uppfyller en ganska stel uppsättning specifikationer, inklusive att de specificeras i Web Services Description Language (WSDL), en XML-variant.

Webbtjänster var avsedda att användas som en del av en serviceorienterad arkitektur (SOA). Som den nordiska API: s blogg förklarar, gav det webbtjänster något av ett dåligt namn, eftersom SOA aldrig riktigt levde upp till sin potential. Framsteg inom teknikerna som används för kommunikation mellan tjänster och tjänster - särskilt lättare, mer flexibel REST - har också lämnat webbtjänster något bakom i världen av offentliga API: er.

REST API: er

Webbtjänster designades ursprungligen för att kommunicera med SOAP (Simple Object Access Protocol), ett meddelandeprotokoll som skickar XML-dokument via HTTP. Idag använder dock de flesta webbaserade API: er REST - Representational State Transfer - som en arkitektonisk stil.

REST introducerades formellt av Roy Fielding i sin doktorsavhandling år 2000. Det är en uppsättning arkitektoniska komponenter, designprinciper och interaktioner som används för att bygga distribuerade system som involverar media av alla slag (text, video etc.). I sin kärna är REST en byggnadsstil som möjliggör flexibel kommunikation och visning av information över webben samtidigt som den ger struktur som är nödvändig för att enkelt bygga komponenter för allmänna ändamål.

I ett REST API kan en resurs vara i stort sett vad som helst, men exempel inkluderar en användare, en lista över tweets och de aktuella resultaten av en sökning efter tweets. Var och en av dessa resurser kan adresseras till en resursidentifierare , som i fallet med webbaserade REST API: er vanligtvis är en URL, till exempel //api.twitter.com/1.1/users/show?screen_name=twitterdev. När ett program begär en resurs med hjälp av identifieraren levererar API: n den aktuella representationen av den resursen till applikationen i ett format som programmet kan konsumera, till exempel en JPEG-bild, HTML-sida eller JSON.

En av de stora skillnaderna för REST är att det handlar om att skicka data till den begärande applikationen. Även om detta ger stor flexibilitet och tillåter applikationen att göra vad den vill med data, kostar det effektiviteten. Att skicka data över webben för bearbetning är ganska långsamt jämfört med att göra behandlingen där uppgifterna finns och sedan skicka resultaten.

Naturligtvis är problemet med det "effektiva" tillvägagångssättet att system som är värd för data skulle behöva veta vad applikationer vill göra med det i förväg. Således, för att bygga ett API som har användbarhet och flexibilitet för allmänt ändamål, är REST vägen att gå.

API-exempel

Det finns gott om offentliga API: er där du kan interagera med, många från branschens behemoter. Möjligheten att få åtkomst till vissa plattformsföretagskoder programmatiskt via ett API är det som gör dem till en plattform. Några framstående API-exempel inkluderar:

  • Google API: er , som låter dig ansluta din kod till hela Googles tjänster, från Maps till Translate. API: er är så viktiga för Google att de förvärvade Apigee, en ledande API-hanteringsplattform.
  • Facebook API: er , som låter dig programmatiskt komma åt Facebooks sociala diagram och marknadsföringsverktyg. (Företaget har begränsat precis vilken användardata du kan komma åt via dessa API: er i nedfallet från Cambridge Analytica och andra skandaler.)

För att verkligen få en känsla av hur API: er fungerar, låt oss göra ett djupt dyk i två: Java API, som Java-utvecklare använder för att interagera med Java-plattformen, och Twitter API, ett offentligt API som du skulle använda för att interagera med det sociala nätverkstjänst.

Java API

Java API är ett bibliotek med mjukvarukomponenter tillgängliga "out of the box" för alla som har installerat Java Development Kit. Dessa komponenter implementerar vanliga uppgifter och ökar i allmänhet produktiviteten eftersom programmerare inte behöver börja om från början varje gång. En av de grundläggande komponenterna som används i programvara är något som kallas en lista, som, som du förväntar dig, håller reda på en lista med objekt. Java API definierar vad du kan göra med en lista: lägg till objekt, sortera listan, avgöra om ett objekt finns i listan etc. Det specificeras också hur dessa åtgärder ska utföras. För att sortera listan måste du ange hur du vill att listan ska sorteras: alfabetiskt, numeriskt fallande, ljusaste till tråkigaste färg etc.

Twitter API

Twitter API är ett webbaserat JSON API som gör det möjligt för utvecklare att programmatiskt interagera med Twitter-data. Till skillnad från Java API, som ingår i Java Development Kit, är Twitter API ett webbaserat API. Det måste nås genom att göra förfrågningar över Internet till tjänster som Twitter är värd för.

Med ett webbaserat API som Twitter skickar din applikation en HTTP-begäran, precis som en webbläsare gör. Men istället för att svaret levereras som en webbsida, för mänsklig förståelse, returneras det i ett format som applikationer enkelt kan analysera. Olika format finns för detta ändamål, och Twitter använder ett populärt och lättanvänt format som heter JSON. (Om du inte känner till JSON kanske du vill spendera några minuter på att läsa upp det här.)

Ett av de grundläggande elementen i Twitter är en tweet. Twitter API berättar vad du kan göra med tweets: sök efter tweets, skapa en tweet, favorit en tweet. Den berättar också hur du utför dessa åtgärder. För att söka efter tweets måste du ange dina sökkriterier: termer eller hashtags att leta efter, geolokalisering, språk etc.

API-design

API-design är den process genom vilken "vad" och "hur" för ett API formuleras. Som med allt annat som kan skapas läggs olika nivåer av tanke och omsorg i API-design, vilket resulterar i varierande nivåer av API-kvalitet. Välutformade API: er har ett konsekvent beteende, tar hänsyn till deras sammanhang och tänker på användarnas behov.

Konsekvent beteende inom ett API påverkar i hög grad den hastighet med vilken det kan läras in och sannolikheten för att programmerare gör misstag när de använder det. I allmänhet bör API: er som utför liknande åtgärder beter sig på samma sätt, oavsett deras tekniska skillnader. För ett exempel på ett inkonsekvent API, låt oss titta på de två sätten att lägga till ett objekt till en lista i Java:

Även om de två metoderna för att lägga till objekt i en lista gör samma sak, är deras returtyper (booleska och ogiltiga) olika. Utvecklare som använder detta API måste nu hålla reda på vilken metod som returnerar vilken typ, vilket gör API svårare att lära sig och dess användning mer felbenägen. Det betyder också att koden som använder dessa metoder blir mindre flexibel, eftersom den måste ändras om du vill ändra hur du lägger till element.

Att ta hänsyn till sammanhang är en annan form av konsistens, även om det har att göra med faktorer utanför API: et. Ett utmärkt, icke-mjukvaruexempel på detta är hur vägregeln - höger- eller vänstertrafik - påverkar bildesign för olika länder. Biltillverkare tar hänsyn till den miljöfaktorn när de lokaliserar förarsätet på höger eller vänster sida av bilen.