Application Programming Interface

Från Wikipedia
(Omdirigerad från API)
Hoppa till: navigering, sök

Ett API eller application programming interface är en regeluppsättning för hur en viss programvara kan kommunicera med annan programvara. Regeluppsättningen beskrivs i princip alltid som en uppsättning funktionsanrop (API:ets kontrakt) som under ordnade former ger tillgång till vissa funktioner. Man säger ofta att man kapslar in funktionerna bakom ett API.

Definition[redigera | redigera wikitext]

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).

Olika klasser av API:er[redigera | redigera wikitext]

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
    • API:er för att skicka e-post
I detta fall talar man ofta om kommersiella API:er eller högnivå-API:er.

Implementation av ett API[redigera | redigera wikitext]

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, olika UNIX-dialekter och MacOS. (Mac OS X är i själva verket också en UNIX-dialekt.) 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.

Generella och specifika API:er[redigera | redigera wikitext]

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.

Välkända API:er[redigera | redigera wikitext]

API:er som de flesta av oss kommer i kontakt med på ett eller annat sätt, exempelvis när vi installerar ett nytt program på vår dator, är

  • DirectX - för 3D-grafik
  • GTK+ - för användargränssnitt
  • OpenGL - för 3D-grafik
  • Win32 - för applikationsprogrammering på Windows
  • ODBC - för databaser

API och Copyright[redigera | redigera wikitext]

2010 stämde Oracle Google för att de hade implementerat Javakod i androids operativsystem och sedan distribuerat det. Google hade inte fått tillåtelse att återanvända Java API. Google vann tvisten därför att man i USA inte får ha copyright på API:er. [1]

API:ets kontrakt[redigera | redigera wikitext]

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[redigera | redigera wikitext]

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å formell kontraktsbeskrivning i Eiffel[redigera | redigera wikitext]

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

Referenser[redigera | redigera wikitext]

  1. ^ Binstock, Andrew. ”Oracle mot Google”. Dr.Dobbs. http://www.drdobbs.com/jvm/oracle-and-the-end-of-programming-as-we/232901227. Läst 7 november 2012.