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 webapplikasjoner) 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 komponenter. 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 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
redigerTypiske bruksområder for et API er for å gi brukere og utviklere tilgang til spesifikke data i en organisasjon/applikasjon. Eksempelvis har 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å 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 LastFM.
En «sosial API» ble lansert av eBay som del av et grensesnitt til det lokasjonsbaserte sosiale nettverket til eBay i 2000.
API-dokumentasjon
redigerDokumentasjonen 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.[1]
REST-API
redigerUtdypende artikkel: Representational state transfer
REST står for 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.[2]
CRUD-stil
redigerHandlingene «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:
| CRUD | HTTP |
|---|---|
| Create | PUT |
| Read | GET |
| Update | PUT |
| Delete | 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 målressurser.[3] POST-metoden er derimot en prosessoperasjon som har målressursspesifikk semantikk som typisk går utenfor omfanget av CRUD-operasjoner.[4]
En annen stil som også er brukt en del kalles Hypermedia as the Engine of Application State (HATEOAS).
Synkrone og asynkrone API-er
redigerEt 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.[5] 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
redigerReferanser
rediger- ^ Dekel, Uri (2009). Improving API Documentation Usability with Knowledge Pushing. Pittsburgh: Institute for Software Research, School of Computer Science.
- ^ Shif Ben Avraham (05.09.2019). «What is REST — A Simple Explanation for Beginners, Part 2: REST Constraints». Besøkt 12.11.2019.
- ^ Fielding, Roy (juni 2014). «Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content, Section 4». IETF. Internet Engineering Task Force (IETF). RFC 7231
. Besøkt 14. februar 2018.
- ^ Roy T. Fielding (20. mars 2009). «It is okay to use POST». roy.gbiv.com. Besøkt 14. april 2020. «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.”»
- ^ Synchronous vs. Asynchronous Writes - Packaged Contact Center Enterprise - Document - Cisco DevNet