Redigerer Programmeringsgrensesnitt

Et '''programmeringsgrensesnitt''', kjent på [[engelsk]] som ''application programming interface'' ('''API'''), er et [[grensesnitt]] i en [[programvare]] som gjør at spesifikke deler av denne kan aktiveres («kjøres») fra en annen programvare. Det betyr at svært enkle applikasjoner (ofte [[webapplikasjon]]er) kan gjøre endringer, kjøre prosesser eller på annen måte behandle data i en større kontekst. Slike samarbeidende programvaredeler betegnes gjerne som [[komponent]]er. Man ser dette ofte brukt i for eksempel behandling av data i en [[database]].

API-et beskriver de metoder som en gitt programvare eller et [[bibliotek (programvare)|bibliotek]] kan kommunisere med. Ofte benyttes API-et som et lag eller grensesnitt mellom høynivå- og lavnivåprogrammering. API-et er abstrakt og fungerer som en regelbok for kall til applikasjonen eller kodebiblioteket. Koden som utføres kalles for en [[implementasjon]]. Eksempelvis er [[Wine]] en implementasjon av [[Win32]]. Typiske prosesser man kan gjøre med et API er kommandoene GET (hvor man henter ut data fra for eksempel en database), PUT (hvor man gjør endringer på spesifikke objekt i for eksempel en database) og POST (hvor man legger til data i for eksempel en database).

==Bruksområder==
Typiske bruksområder for et API er for å gi brukere og utviklere tilgang til spesifikke data i en organisasjon/applikasjon. Eksempelvis har [http://www.last.fm/api LastFM et åpent API] hvor man kan blant annet hente ut informasjon om tid og sted for konserter, sanger på et album, informasjon om en artist, med mer. Ved å tilby en slik tjeneste vil altså [http://www.last.fm/home LastFM] tilby sine tjenester på en indirekte måte ved at «hvem som helst» kan utvikle en applikasjon som benytter seg av data levert av [http://www.last.fm/home LastFM].

En «sosial API» ble lansert av [[eBay]] som del av et [[grensesnitt]] til det [[lokasjonsbaserte sosiale nettverk]]et til eBay i 2000.

== API-dokumentasjon ==
Dokumentasjonen for et programmeringsgrensesnitt beskriver hvilke tjenester som tilbys og hvordan det skal brukes. Formålet med dokumentasjonen er å gi brukeren nødvendig informasjon for å kunne gjøre API-kall og få tilbake data.

Dokumentasjonen for et API er essensiell for en utvikler ettersom at den definerer hva slags kode som skal skrives i applikasjonen til utvikleren.<ref>{{Kilde bok|tittel=Improving API Documentation Usability with Knowledge Pushing|etternavn=Dekel|fornavn=Uri|utgiver=Institute for Software Research, School of Computer Science|år=2009|isbn=|utgivelsessted=Pittsburgh|side=|sider=|kapittel=|sitat=}}</ref>

== REST-API ==
{{hoved|Representational state transfer}}
REST står for [[Representational state transfer|REpresentational State Transfer]]. Når et REST-API kalles, vil serveren overføre en representasjon av tilstanden til den etterspurte ressursen. Denne representasjonen kan være skrevet i [[JSON]], [[XML]] eller [[HTML]] format.

En REST webapplikasjon eksponerer informasjon om tjenestene til klienter. Klientene kan utføre oppgaver basert på denne informasjonen.

For at et API skal være et REST-API må det følges et sett med begrensninger når det skrives. Disse begrensningene vil gjøre det enklere for utviklere som har mindre erfaring med API-kall.<ref>{{Kilde www|url=https://medium.com/extend/what-is-rest-a-simple-explanation-for-beginners-part-2-rest-constraints-129a4b69a582|tittel=What is REST — A Simple Explanation for Beginners, Part 2: REST Constraints|besøksdato=12.11.2019|forfattere=Shif Ben Avraham|dato=05.09.2019|forlag=|sitat=}}</ref>

=== CRUD-stil ===
Handlingene «[[opprett, les, oppdater og slett]]» (engelsk: ''create, read, update and delete'', CRUD) er fire grunnleggende operasjoner når det gjelder lagring av data. CRUD-begrepet brukes generelt innen IT for å beskrive en konvensjon for brukergrensesnitt som skal gjøre det enklere å finne, lese og endre informasjon. CRUD-stilen er også en vanlig stil å benytte for utforming av REST API-er, og forstås da å bety følgende [[HTTP]]-metoder:

{| class="wikitable"
|-
! CRUD
! HTTP
|-
| Create
| [[Hypertext Transfer Protocol#Request methods|PUT]] <!-- Do not replace with POST which is not a CRUD operation (cf. below). -->
|- <!-- POST should be added.
POST is a CRUD operation in the same way as SQL INSERT. 
If the key is specified in INSERT, then the equivalent REST is indeed PUT. 
On the other hand, if a table autogenerates the key and the INSERT doesn't have the key, then the equivalent REST is POST.

"that doesn’t mean we can live without it. POST serves many useful purposes in HTTP." It is the standard way of creating a new object where the server assigns the id. We can't help that in all other ways, POST is as loosy goosy as Roy said.

The user agent doesn't always have the onus of knowing the key/id when creating in web or relational databases. Knowing the key when creating is NOT a requirement of CRUD, SQL, or REST. -->
| Read
| [[Hypertext Transfer Protocol#Request methods|GET]]
|-
| Update
| [[Hypertext Transfer Protocol#Request methods|PUT]]
|- <!-- PATCH should be added. In the same way where SQL UPDATE can replace all or part of a row. 
 PUT replaces the entire entity. PATCH replaces part of the entity. 
On the other hand, if a table autogenerates the key and the INSERT doesn't have the key, then the equivalent REST is POST. -->
| Delete
| [[Hypertext Transfer Protocol#Request methods|DELETE]]
|}

I HTTP er metodene GET (les), PUT (opprett og oppdater) og DELETE (slett) CRUD-operasjoner ettersom de har [[semantikk]] for lagringsadministrasjon, hvilket betyr at de lar brukeragenter direkte manipulere tilstandene til [[vevressurs|målressurser]].<ref>{{cite web |url=https://tools.ietf.org/html/rfc7231#section-4 |title=Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content, Section 4 |last=Fielding |first=Roy |date=juni 2014 |website=IETF |publisher=Internet Engineering Task Force (IETF) |access-date=2018-02-14 |rfc=7231}}</ref> POST-metoden er derimot en prosessoperasjon som har målressursspesifikk semantikk som typisk går utenfor omfanget av CRUD-operasjoner.<ref name="it-is-okay-to-use-post">{{cite web|url=https://roy.gbiv.com/untangled/2009/it-is-okay-to-use-post |title=It is okay to use POST |author=Roy T. Fielding |publisher=roy.gbiv.com |date=2009-03-20 |access-date=2020-04-14 |quote=POST only becomes an issue when it is used in a situation for which some other method is ideally suited: e.g., retrieval of information that should be a representation of some resource (GET), complete replacement of a representation (PUT), or any of the other standardized methods that tell intermediaries something more valuable than “this may change something.” The other methods are more valuable to intermediaries because they say something about how failures can be automatically handled and how intermediate caches can optimize their behavior. POST does not have those characteristics, but that doesn’t mean we can live without it. POST serves many useful purposes in HTTP, including the general purpose of “this action isn’t worth standardizing.”}}</ref>

En annen stil som også er brukt en del kalles ''Hypermedia as the Engine of Application State'' (HATEOAS).

== Synkrone og asynkrone API-er ==
Et programmeringsgrensesnitt kan være synkront eller asynkront. Et synkront API-kall er et designmønster hvor anropssiden blokkeres mens den venter på at den kalte koden skal fullføres.<ref>[https://developer.cisco.com/docs/packaged-contact-center/#!synchronous-vs-asynchronous-writes Synchronous vs. Asynchronous Writes - Packaged Contact Center Enterprise - Document - Cisco DevNet]</ref> Med et asynkront API-kall blokkeres imidlertid ikke kallstedet mens det venter på at den kalte koden skal fullføres, og istedet får tråden som kalte beskjed når resultatet er ferdig.

==APIer for Windows==
*[[DirectX]]
*[[GTK+]]
*[[OpenGL]]
*[[Win32]]

==Referanser==
<references/>

{{Autoritetsdata}}

[[Kategori:Grensesnitt for programvare| ]]