API er den aftale, systemerne taler efter
API står for Application Programming Interface. På almindeligt dansk er det en aftale om, hvordan et system kan spørge et andet system om data eller bede det udføre en handling.
Når en webshop sender en ordre til et lagersystem, eller en hjemmeside henter boliger fra en ekstern database, sker det ofte gennem et API. Brugeren ser måske bare en opdateret liste. Bagved bliver data sendt i et fast format med regler for, hvad der må læses og ændres.
Et eksempel uden teknisk tåge
Forestil dig en restaurant med online booking. Hjemmesiden spørger bookingsystemet: “Er der et bord til fire fredag klokken 19?” Systemet svarer ja eller nej. Når kunden booker, sender hjemmesiden oplysningerne tilbage. API’et beskriver adresserne, felterne og de svar, systemerne bruger.
Det minder om en tjener, der tager imod en bestilling efter en fast procedure. Køkkenet behøver ikke kende gæsten, og gæsten behøver ikke gå ud i køkkenet. Grænsefladen holder rollerne adskilt.
REST, endpoints og JSON — tre ord du ofte møder
Mange web-API’er er REST-baserede. Et endpoint er en bestemt adresse til en bestemt type data, eksempelvis “ordrer” eller “produkter”. JSON er et almindeligt tekstformat til at sende felter og værdier.
En WordPress-side har eksempelvis et REST API, som kan læse og oprette indhold, hvis adgang og rettigheder er sat korrekt op. WooCommerce har tilsvarende muligheder for produkter og ordrer.
Det svære er sjældent den første vellykkede test
En udvikler kan ofte få to systemer til at udveksle et eksempel hurtigt. Den virkelige opgave begynder bagefter. Hvad sker der, hvis det ene system er nede? Hvis et obligatorisk felt mangler? Hvis den samme ordre bliver sendt to gange? Hvis en adgangsnøgle udløber?
- Log fejl med nok information til at kunne finde dem.
- Undgå dubletter ved at bruge entydige ID’er.
- Aftal hvad der er hovedsystem for hvert felt.
- Håndtér timeout og midlertidige driftsproblemer.
- Begræns adgang til præcis de data, integrationen behøver.
Sikkerhed handler om mere end at gemme en nøgle
API-nøgler og tokens skal behandles som adgangskoder. De bør ikke ligge synligt i browserkode eller sendes rundt på mail. Rettighederne bør være så snævre som muligt. En integration, der kun skal læse produkter, har ikke brug for adgang til at slette ordrer.
Persondata kræver også omtanke. Bare fordi to systemer teknisk kan udveksle alt, betyder det ikke, at de skal.
Hvornår giver en integration mening?
Hvis medarbejdere kopierer de samme data mellem systemer hver dag, kan en integration spare tid og fejl. Hvis opgaven sker to gange om året, kan automatiseringen være dyrere at bygge og vedligeholde end det manuelle arbejde.
Hos et webbureau bør den første samtale derfor handle om arbejdsgangen, ikke om teknologien. Hvilket problem skal væk? Hvem ejer data? Hvor hurtigt skal ændringer slå igennem?
Webhook og API bliver ofte nævnt i samme sætning
Et almindeligt API-kald sker, når system A spørger system B. En webhook går den anden vej: system B sender automatisk en besked, når noget sker. En webshop kan eksempelvis sende en webhook, når en ordre er betalt, så lagersystemet ikke skal spørge hvert minut.
De to teknikker bruges ofte sammen. API’et kan hente de fulde detaljer, mens webhooken fortæller, at der er noget nyt at hente.
Dokumentation er en del af leverancen
En integration bør beskrive endpoints, felter, adgang, fejlkoder og ejerforhold. Ellers bliver selv en lille ændring dyr, fordi næste udvikler først skal gætte sig til, hvordan systemet hænger sammen. Dokumentationen skal opdateres, når integrationen ændres — ikke ligge som et screenshot fra første test.
Sandkassedata og rigtige data opfører sig ikke altid ens
Mange leverandører tilbyder et testmiljø, hvor integrationen kan udvikles uden at påvirke rigtige kunder. Det er godt, men testdata er ofte pænere end virkeligheden. Rigtige navne har bindestreger, adresser mangler etage, og ordrer kan blive refunderet delvist.
Lav derfor en kontrolleret pilot med realistiske scenarier før fuld drift. Test også æ, ø og å, store datamængder og handlinger, der bliver udført i en uventet rækkefølge.
Husk også ejerskab: Virksomheden bør have adgang til nøgler, dokumentation og leverandørkonti. En integration må ikke kun eksistere på en udviklers private konto.
Et API er ikke “sæt op og glem”
Leverandører ændrer versioner, felter og krav. Integrationer skal overvåges og opdateres. En god løsning har dokumentation og en tydelig plan for fejl — også den dag den oprindelige udvikler ikke sidder ved computeren.
Senest opdateret
