Applikationsprogrammeringsgränssnitt

Den här artikeln behöver fler eller bättre källhänvisningar för att kunna verifieras. (2019-05) Åtgärda genom att lägga till pålitliga källor (gärna som fotnoter). Uppgifter utan källhänvisning kan ifrågasättas och tas bort utan att det behöver diskuteras på diskussionssidan.

API:et är ett gränssnitt mellan applikationen och biblioteket. Biblioteket blir en mjukvarukomponent i applikationen och utgörs vanligen av en uppsättning funktioner som är tillgängliga för applikationen att anropa, variabler som den kan läsa och/eller ändra, samt datatyper och klasser som den kan använda. Dessa funktioner kan i sin tur använda funktioner, variabler, och så vidare, som inte har gjorts tillgängliga från externa program, utan har kapslats in bakom API:et.

De flesta programvaror i dagens läge är applikationer som knyter samman annan mjukvarufunktion i olika former och skapar en meningsfull helhet, och denna sammanknytning sker med hjälp av API:er. API:er ger alltså möjlighet att på ett strukturerat sätt återanvända redan utvecklad och kvalitetssäkrad mjukvara som har kapslats in i någon form av kodbibliotek (eng: library). I någon mening kan man säga att ett API är de yttre attributen för en abstrakt datatyp.

Ett välformat API är till sin natur lite "abstrakt" i den meningen att det beskriver en funktion utan att berätta något om hur denna funktion implementeras (ett API som förutsätter något om den underliggande implementationen sägs vara icke välformat).

Man kan särskilja två olika typer av API:er:

• API:er som ger tillgång till olika typer av systemresurser, ofta utan att fästa avseende vid vilket operativsystem programmet ska användas på. Exempel:
  • Skrivare
  • Filhantering
  • Grafikhantering
  • Radiokretsar (exempelvis WLAN eller Bluetooth)

I detta fall talar man om drivrutins-API:er. API:et används som ett lager mellan högnivåprogrammering och lågnivåresurser (systemresurser).

• API:er som ger tillgång till högnivåfunktioner som återanvänds på ett eller annat sätt. Här rör det sig ofta om mjukvara som tillhandahålls av andra leverantörer för olika typer av datahantering eller beräkningar. Exempel:
  • Matrisberäkningsbibliotek^{[förtydliga]}
  • API:er för att skicka e-post

I detta fall talar man ofta om kommersiella API:er eller högnivå-API:er.

Den programkod som utför det API:et är tänkt att utföra för kallas API:ets implementation. Det existerar ofta ett flertal implementationer för ett visst API, exempelvis för olika operativsystem såsom Windows och olika UNIX-dialekter såsom Linux och Mac OS Classic. Ett API kan implementeras i snart sagt vilket programspråk som helst i vilken operativsystemsmiljö som helst, så länge som det är möjligt för en programmerare att använda det.

Man skiljer också på generella och specifika API:er:

• Ett generellt API beskriver ett generellt sätt att använda en viss systemresurs eller annan resurs. Exempel är printer-API:er och grafik-API:er såsom OpenGL. Denna typ av API:er tillåter en mjukvaruutvecklare att skapa en programvara som är väldigt flexibel och som kan flyttas mellan olika hårdvaruarkitekturer och operativsystem utan att ändras.
• Ett specifikt API ger tillgång till en specifik resurs, ofta en hårdvaruresurs såsom ett specialiserat GPS-chip eller liknande. Denna typ av API:er är vanliga på mer specialiserade hårdvaruarkitekturer.

API:er som många kommer i kontakt med på ett eller annat sätt, exempelvis när man installerar ett nytt program på sin dator, är:

• DirectX – för 3D-grafik
• GTK+ – för användargränssnitt
• OpenGL – för 3D-grafik
• Win32 – för applikationsprogrammering på Windows
• Open Database Connectivity (ODBC) – för databaser

2010 stämdes Google av Oracle för att ha implementerat Javakod i Androids operativsystem och sedan distribuerat det. Google hade inte fått tillåtelse att återanvända Java API. Oracle vann tvisten genom ett avgörande i maj 2015.^{[ej i angiven källa]}

Termen kontrakt används ibland som en benämning på en kvasiformell beskrivning på hur, och vilka villkor som ska vara uppfyllda, för att ett API eller en API-funktion ska anropas. Termen kontrakt används också mer formellt i den engelska termen "Design by Contract" (DbC) och avser då en formell specifikation av ett API eller en API-funktion som också utgör en faktisk del av källkoden. Sådana kontrakt möjliggör således kontroll av villkor när anrop till ett API eller API-funktion faktiskt görs. DbC har oftast implementerats i objektorienterade programmeringsspråk.

DbC utvecklades av Bertrand Meyer och har sitt teoretiska ursprung i Tony Hoares Hoare-logik och Jean-Raymond Abrials arbete med Z-notation. "Design by Contract" implementerades först i programmeringsspråket Eiffel och beskrevs först 1986. Stöd för DbC finns idag i flera programmeringsspråk, däribland Ada 2012 och D. Att använda DbC kallas ibland för kontraktsprogrammering.

Ett exempel på kvasiformell beskrivning

Ett kvasiformellt kontrakt för ett matematikbibliotek som tillhandahåller funktionerna Min(...) och Max(...) för heltal kan se ut på följande sätt:

Kontrakt för MinMax --- Funktioner:   int Max(int a, int b)   Funktion: Max(...) returnerar det större talet av de två inparametrarna a och b   Returvärdets datatyp är heltal (int)   Sidoeffekter: Inga.     int Min(int a, int b)   Funktion: Min(...) returnerar det mindre talet av de två inparametrarna a och b   Returvärdets datatyp är heltal (int)   Sidoeffekter: Inga. 

Ett exempel på kontrakt för en funktion för att lägga till element (ELEMENT) i en hashtabell (DICTIONARY) kan se ut så här:

  put (x: ELEMENT; key: STRING) is      -- Insert x so that it will be retrievable through key.      require         count ⇐ capacity         not key.empty      do         ... Some insertion algorithm ...      ensure         has (x)         item (key) = x          count = old count + 1      end 

En API-transformator är en kraftfull lösning som gör att man kan omvandla API-specifikationer till vilket format som helst. Den kan stödja ett brett utbud av olika format.