Hvordan fungerer API'er i backend-udvikling?
Hvad er en API, og hvorfor er den central i backend-udvikling?
En API, Application Programming Interface, er et sæt regler og konventioner, der bestemmer, hvordan to systemer kan kommunikere med hinanden. I backend-udvikling er API'er det lag, der forbinder din servers logik med omverdenen: mobilapps, hjemmesider, tredjeparts-tjenester og andre systemer.
Forestil dig en restaurant. Tjeneren tager imod din bestilling og bringer den videre til køkkenet, som tilbereder maden og sender den tilbage. Tjeneren er API'en. Du som gæst behøver ikke vide, hvad der foregår i køkkenet, du kommunikerer kun med tjeneren. På samme måde behøver en app ikke kende til databasestrukturen bag en tjeneste. Den sender en forespørgsel til API'en og modtager et svar.
I praksis vil din backend sjældent fungere som ét lukket system. Den skal typisk kommunikere med betalingsløsninger, loginudbydere, kortvisning, notifikationstjenester og meget mere. Det er her API'er gør det muligt at bygge komplekse systemer uden at opfinde alt fra bunden.
REST og andre API-arkitekturer
Der er flere måder at strukturere en API på, men i backend-udvikling dominerer REST i dag, og det er det, de fleste udviklere støder på først.
REST, Representational State Transfer
En REST API er bygget op om HTTP-protokollen og bruger standardmetoder som GET, POST, PUT, PATCH og DELETE til at udføre handlinger på ressourcer. En ressource kan være alt fra en bruger til en ordre eller et produkt.
Et eksempel: Vil du hente en liste over alle brugere, sender du en GET-forespørgsel til /api/users. Vil du oprette en ny bruger, sender du en POST-forespørgsel til samme endepunkt med brugerens data i forespørgslens krop. Svaret kommer typisk tilbage som JSON, et letlæseligt tekstformat, som både maskiner og mennesker kan forstå.
REST er populær, fordi den er simpel, fleksibel og bygger på teknologi, som alle moderne systemer allerede understøtter.
GraphQL
GraphQL er et alternativ, der er særligt nyttigt, når klienten selv skal bestemme, præcis hvilke data den modtager. I stedet for mange specifikke endepunkter har du ét, og klienten formulerer en forespørgsel, der præcis beskriver, hvad den ønsker. Det reducerer overfetch, at hente mere data end nødvendigt, og underfetch, at hente for lidt og skulle sende en ekstra forespørgsel.
gRPC
gRPC bruges ofte i systemer, hvor ydeevne og hastighed er kritisk, for eksempel kommunikation mellem mikrotjenester internt i en applikation. Det er mere teknisk komplekst end REST, men giver til gengæld meget hurtigere kommunikation.
Autentificering og autorisation i API'er
En åben API uden adgangskontrol er en sikkerhedsrisiko. Backend-udviklere bruger derfor autentificering til at bekræfte, hvem der kalder API'en, og autorisation til at afgøre, hvad de har lov til.
API-nøgler
Den simpleste form er en API-nøgle, en unik streng, som klienten sender med i hver forespørgsel, typisk i en header. Det bruges meget til server-til-server-kommunikation, men er ikke nok alene til brugerspecifikke handlinger.
OAuth 2.0 og JWT
Til brugerbaserede systemer er OAuth 2.0 standarden. Den håndterer, at en bruger kan logge ind via Google eller Facebook, og at din backend derefter modtager en adgangstoken. JSON Web Token, JWT, er et populært format til sådanne tokens. Et JWT indeholder krypteret information om brugeren og udløbstidspunktet og kan verificeres af din backend uden at konsultere en database ved hvert kald.
Korrekt autentificering er ikke valgfrit. Mangler den, kan uvedkommende tilgå andres data, manipulere indhold eller belaste systemet unødvendigt. Hvis du vil dykke dybere ned i, hvad en moderne backend kræver, kan du med fordel læse om cloud-løsninger i backend-udvikling, som også berører sikkerhed og skalerbarhed.
Fejlhåndtering og HTTP-statuskoder
En god API kommunikerer tydeligt, hvad der gik galt, og hvornår alt gik godt. Det gør den via HTTP-statuskoder.
De mest anvendte:
- 200 OK, forespørgslen lykkedes, og data returneres.
- 201 Created, en ressource blev oprettet.
- 400 Bad Request, klienten sendte en ugyldig forespørgsel.
- 401 Unauthorized, manglende eller ugyldig autentificering.
- 403 Forbidden, autentificeret, men ikke autoriseret til denne handling.
- 404 Not Found, ressourcen eksisterer ikke.
- 500 Internal Server Error, noget gik galt på serverens side.
Ud over statuskoden bør API'en returnere en beskrivende fejlbesked i svarkroppen. "Error: invalid_email" er langt mere brugbart end blot en 400-kode uden kontekst. God fejlhåndtering sparer enormt meget tid under udvikling og fejlsøgning.
Versionstyring af API'er
Systemer ændrer sig over tid. Nye funktioner tilføjes, og gamle endepunkter skal måske ændres. Her opstår et problem: Ændrer du en API, kan alle eksisterende klienter, der bruger den, gå i stykker.
Løsningen er versionstyring. Den mest udbredte tilgang er at inkludere versionen i URL-stien, for eksempel /api/v1/users og /api/v2/users. Dermed kan du køre to versioner parallelt, mens ældre klienter migrerer i eget tempo.
Det er god praksis at definere en politik for, hvor lang tid ældre versioner understøttes, og kommunikere det tydeligt til udviklerne, der bruger API'en.
Rate limiting og ydeevne
En backend, der besvarer ubegrænsede forespørgsler per sekund fra en enkelt klient, er sårbar over for misbrug, enten fra fejlbehæftet kode eller fra ondsindede angreb. Rate limiting begrænser, hvor mange forespørgsler en klient kan sende inden for et givet tidsrum.
Udover sikkerhed handler det om ydeevne. Caching er en af de mest effektive teknikker: I stedet for at din backend beregner det samme svar igen og igen, gemmes resultatet i en kort periode og genbruges. For endepunkter med hyppige opkald og sjældent skiftende data kan caching reducere serverbelastningen markant.
Pagination er en anden vigtig teknik. Returnerer et endepunkt potentielt tusindvis af poster, bør du opdele svaret i sider frem for at sende alt på én gang. Det sparer både server og klient for unødvendigt arbejde.
Dokumentation er ikke valgfrit
En API er kun nyttig, hvis de udviklere, der skal bruge den, forstår, hvordan den virker. Dokumentation er derfor ikke et efterfølgende skridt, det er en del af selve produktet.
Standarden i branchen er OpenAPI-specifikationen (tidligere kaldet Swagger), som giver et maskinlæsbart format til at beskrive endepunkter, parametre og svarformater. Mange værktøjer kan auto-generere interaktiv dokumentation fra denne specifikation, så udviklere kan teste kald direkte i browseren.
God dokumentation indeholder eksempler på både vellykkede forespørgsler og fejlscenarier. Det reducerer support-henvendelser og gør det langt lettere at integrere mod API'en. Er du nysgerrig på, hvilke kompetencer der efterspørges i forbindelse med netop denne type arbejde, kan du læse om de mest efterspurgte færdigheder inden for webudvikling.
Webhooks, den omvendte API
En klassisk API er reaktiv: Din klient spørger, og serveren svarer. Men hvad nu, hvis du vil have besked, så snart noget sker på serveren, for eksempel, at en betaling er gennemført?
Her kommer webhooks ind. En webhook er en HTTP-forespørgsel, som din backend sender til en på forhånd defineret URL, så snart en bestemt hændelse indtræffer. Du behøver ikke spørge gentagne gange, du modtager blot en notifikation, når det er relevant.
Webhooks bruges i vid udstrækning i betalingsløsninger, booking-systemer og integrationsplatforme, og de er et vigtigt supplement til den klassiske forespørgsel-svar-model.
Hvad du skal have styr på, inden du bygger en API
Inden du sætter dig ned og begynder at kode, er der en håndfuld spørgsmål, der er værd at besvare:
- Hvem er forbrugerne af API'en, interne tjenester, mobilapps, tredjeparter?
- Hvilken arkitektur passer til behovet, REST, GraphQL eller noget andet?
- Hvilke data er følsomme, og hvilke sikkerhedskrav stiller det?
- Hvordan skalerer API'en, hvis trafikken stiger markant?
- Hvordan vil du håndtere bagudkompatibilitet, når API'en ændres?
Disse beslutninger er svære at vende bagefter. En gennemtænkt arkitektur fra starten sparer betydelige mængder refaktoreringsarbejde på sigt. Har du en eksisterende platform, der trænger til opdatering, er der god vejledning at hente i denne artikel om optimering af en eksisterende softwareplatform.
Afsluttende betragtninger
API'er er ikke blot et teknisk detailspørgsmål, de definerer, hvor fleksibel, sikker og vedligeholdelsesvenlig din backend er på lang sigt. En veldesignet API er nem at forstå, svær at misbruge og nem at udvide. En dårligt designet API er til gengæld kilden til fejl, frustration og teknisk gæld.
Uanset om du bygger fra bunden eller integrerer mod eksisterende systemer, betaler det sig at bruge tid på arkitekturen, sikkerhedslaget og dokumentationen tidligt i processen.
Har du et projekt, hvor backend-arkitekturen skal besluttes, er du velkommen til at tage en uforpligtende snak med Sahari, der arbejder med netop denne type udvikling til daglig.