Code First vs. API First: Vigtigheden af APIer i det digitale landskab

Den digitale verden bliver mere og mere kompleks. Alt foregår efterhånden online, og informationer, funktioner og platforme er forbundet på kryds og tværs. Det sætter store krav til API’er og gør API First-tilgangen relevant som aldrig før. Læs og lær her.

Hvis du har læst vores tidligere blogindlæg om Microservices, ved du, at mange moderne, digitale løsninger i høj grad afhænger af API’er.

Det skyldes blandt andet, at moderne løsninger og platforme opbygges af mindre komponenter, som kommunikerer gennem disse Application Programming Interfaces. Men også behovet for at dele informationer mellem forskellige virksomheder og datakilder har øget kravene til udviklingen af API’er.

Lyder det som volapyk? Bare rolig.

Når du har læst dette indlæg, har du en grundlæggende forståelse for, hvad et API er; hvilke typer APIer, der findes og hvilke fordele der er ved API First i modsætning til den traditionelle tilgang til webudvikling, bedre kendt som “Code First”.

Lad os starte fra bunden. Et API er en forkortelse for den engelske betegnelse Application Programming Interface. Mange tænker nok forenklet på det som bindeleddet, der får forskellige systemer til at snakke sammen. Det er i store træk også korrekt.

Et API gør det nemlig muligt for forskellige applikationer, programmer eller systemer at kommunikere og udveksle teknisk data og indhold mellem hinanden.

Det er fx takket være API’er, at du kan logge ind på Spotify via Facebook, og at Skyscanner er i stand til at indhente og vise dig priser fra hundredvis af flyselskaber.

På et mere internt niveau bruges APIer fx til at udvikle plugins, tilføje funktionalitet til en digital løsning og forbinde interne databaser og software – eksempelvis ved integration mellem din webshop og dit økonomisystem eller dit PIM-system.

API er en protokol for udveksling af data

Mere teknisk er en API en form for protokol, der beskriver proceduren for at kommunikere med og indhente data fra en given applikation.

Blandt andet kan et API definere nogle tekniske krav og regler, som skal opfyldes og følges. Det kan fx være i forhold til godkendelse af brugeren, specifikation af dataformater, præcis definition af de forespurgte oplysninger og den ønskede metode til at modtage eller sende data.

Dermed udgør API’er også en stor sikkerhedsmæssig faktor, fordi det er i stand til at blokere og nægte adgang til data for systemer, robotter og andre uvedkommende, der ikke lever op til de definerede krav.

API’er udvikles til forskellige formål og kan overordnet inddeles i 4 kategorier. Disse kategorier er:

Interne APIer

Interne API’er bruges primært til at optimere workflows og kommunikation internt i en virksomhed. De bruges som bindeled, når man integrerer forskellige forretningsapplikationer og -systemer, såsom ERP, CRM og webshops.

Interne API’er bruges i høj grad også til Headless-løsninger, hvorved deres opgave er at forbinde frontend og backend. Ligeledes bruges de til at sammenkoble flere små komponenter og funktioner (mircoservices) til en samlet digital løsning.

Åbne APIer

Nogle virksomheder udvikler API’er, som de lægger ud på nettet frit tilgængeligt for alle, der skulle ønske at benytte sig af dem. Flere vejrstationer giver dig for eksempel mulighed for at bruge deres API’er, så du kan trække deres data og vise vejrudsigten på din egen platform. Det kan være et brugbart værktøj, hvis du for eksempel ejer en campingplads i et solfyldt område i Spanien.

Ligeledes har for eksempel Facebook og Instagram (og utallige andre virksomheder) åbne API’er liggende offentligt tilgængeligt, som tredjepartsvirksomheder kan benytte sig af. Det gør det for eksempel muligt at integrere dit Instagram-feed på din webshop.

Partner APIer

Partner API’er er – som navnet antyder – målrettet en virksomheds partnere eller særligt udvalgte kunder. De kræver altså en godkendelse eller aftale mellem udbyderen og den, som ønsker at benytte sig af AP’Iet.

Uber har for eksempel givet TripAdvisor og United Airlines mulighed for at integrerer ”Book en Uber” på deres egen platform gennem et Partner API. Derved kan TripAdvisors og United Airlines’ brugere lettere skaffe et lift til lufthavnen eller museet – uden at skulle famle rundt mellem flere forskellige apps. Det giver bedre brugeroplevelser og er altså en gevinst for alle parter.

Composite APIer

Den danske oversættelse for composite er sammensat. Disse API’er sammensætter – eller kombinerer – funktionen af flere forskellige API’er, og derved kan samtlige opgaver, de hver især oprindeligt skulle håndtere individuelt, udføres sideløbende i ét trin. Målet er at øge hastighed og optimere performance på en funktionalitet.

Et Composite API kan anvendes i en bred vifte af applikationer. Det kan for eksempel bruges i marketing dashboards, hvor man ønsker at trække data om en målgruppe fra både Instagram, Twitter og Facebook simultant. Men det kan også være inden for rejsebranchen, hvor man med én søgning ønsker at give et fuldt overblik over både fly, hoteller og biludlejning.

Nu til det, du nok kom for. For hvad er API First og hvorfor er det smart?

Fænomenet ”API First” begyndte for alvor at blomstre med udbredelsen af Headless-løsninger og microservices-applikationer.

Det skyldes, at disse typer moderne, fleksible løsninger bygges op af en masse små enkeltdele, som bindes sammen af netop API’er. Og derfor får API’erne en helt central rolle.

Dette er i modsætning til traditionelle, monolitiske løsninger, hvor al funktionalitet var kodet ind i én og samme kodebase, og API’erne derfor var mindre essentielle.

Desuden har et stigende behov for at udveksle data på tværs af systemer og virksomheder gjort API First ekstra relevant.

Det nye digitale landskab har tvunget webudviklere til at tænke anderledes og se på deres opgaver fra et nyt perspektiv. Det har resulteret i, at man er gået fra en traditionel, kodeteknisk Code First-tilgang til en mere brugerorienteret API First-tilgang.

Lad os prøve at få lidt perspektiv på det ved at sammenligne de to.

Code First og API First beskriver altså to forskellige tilgange til webudvikling: En traditionel, og en mere moderne.

Code First

Ved en traditionel Code First-tilgang begynder man at kode løsningen og sikrer, at funktionaliteten er til stede. Først bagefter overvejer man, hvordan denne funktionalitet skal eksponeres gennem API’er. Fordelen ved Code Først er, at man lynhurtigt kan få en funktionel prototype og en løsning, som i sit store hele fungerer. Men det kan også få nogle konsekvenser hen ad vejen. Mere om det senere.

Code First-tilgangen kan ridses op således:

• Løsningens kernefunktioner kodes, før API’erne udvikles.
• API’er anses for at være et understøttende komponent i løsningen.
• API’erne har en taktisk funktion.
• Tilknytning af komplette tredjepartssystemer, hvilket ofte resulterer i en tungere løsning end nødvendigt.

API First

Webudviklere, der arbejder API First behandler API’erne som “førsteklassesborgere”, og kodning af selve løsningen kommer sekundært. Det tvinger udviklerne til – tidligt i processen – at stille skarpt på en række essentielle spørgsmål. Blandt andet: Hvilke data og funktionaliteter har brugeren behov for? Hvor kommer disse data fra? Hvordan skal de tilgås? Og hvem ellers skal have adgang til disse? Når API’erne er lavet, bygger man systemet rundt om dem.

API First-tilgangen kan ridses op således:

• API’erne defineres, før selve løsningen kodes.
• API’erne anses for selvstændige produkter.
• API’erne får en strategisk funktion.
• Tilknytning af nøje udvalgte moduler fra et tredjepartssystem, så man kun får nøjagtig den funktionalitet, man skal bruge.

Om man udvikler det ene eller det andet først, kan vel komme ud på ét – tænker du måske.

Og jo, det vil enhver logik sige. Men her må du ikke lade dig narre.

Fordi man med API First tvinges til at gøre sig nogle essentielle tanker og overvejelers tidligt i processen, vil man ende med en langt mere velstruktureret løsning.

Det vil komme til udtryk på særligt 3 punkter.

API First er vejen frem i det moderne, digitale landskab. Men der er absolut også nogle faktorer og risikozoner, du skal tage højde for.

Bygger du en løsning, som i høj grad afhænger af eksterne virksomheders API’er (fx til at inkorporere funktionalitet på dit eget site, som du ikke selv har udviklet eller kodet), kan det føre til en vis sårbarhed. Du skal stole på, at de eksterne virksomheder, som har stillet API’et til rådighed, vedligeholder dem og ikke pludseligt trækker dem tilbage fra markedet.

Omvendt: Hvis din virksomhed selv udvikler API’er til brug for andre, bærer du ansvaret for at sikre, at API’erne er korrekt dokumenteret og vedligeholdt. Det gælder især, hvis du tager betaling for brugen af API’erne eller de spiller en strategisk vigtige for dig og dine partnere.

Alle virksomheder, hvis koncept eller forretningsstrategi kan have gavn af, at deres moduler og funktioner kan integreres på eksterne sites, er nødt til at være API First.

Det samme bør virksomheder, der har behov for at kunne udveksle, levere eller synkronisere data med partnere og løsninger internt.

Særligt kan vi fremhæve:

Finansielle institutioner
Banker, forsikringsselskaber og andre finansielle institutioner har ofte behov for at kunne håndtere betalinger, transaktioner, dataudveksling og integrationer med eksterne partnere. Derfor er velskabte API’er enormt vigtige – både i forhold til sikkerhed, men også i forhold til at skabe en strømlinet brugeroplevelse.

Rejse- og transportindustrien
Virksomheder inden for rejse- og transportsektoren, såsom flyselskaber, hoteller, rejsebureauer og transportplatforme, kan udnytte API First-tilgangen til at integrere med flyreservationssystemer, hotelbookingplatforme, transporttjenester og lignende. Dette gør det muligt for dem at tilbyde en bred vifte af tjenester og skabe en mere komplet rejseoplevelse for deres kunder.

Udbydere af SaaS-løsninger
Digitale løsninger, som skal tilbydes som en SaaS (Software-as-a-service) – herunder forretningssystemer, e-mail platforme, e-handelsløsninger m.fl – afhænger af API First. API First sikrer, at løsningen nemt kan integreres med slutbrugerens eksisterende systemer og tredjepartsapplikationer.

Webshops og andre eCommerce-løsninger
Salgsplatforme kan ikke komme udenom APIer. Disse bruges til integration til økonomisystemer, shipping og logisting, produktkataloger samt payment gateways og så videre. Men også moduler som kundeudtalelser fra Trustpilot og visning af dit Instagram-feed på webshoppen kræver brug af APIer. Sælges dine produkter på flere forskellige kanaler, benyttes APIer ligeledes til at sikre samspil og kontinuitet på tværs.

Kædesamarbejder og e-Handelskæder
Virksomheder, der arbejder på tværs i et større kædesamarbejde, vil have stor gavn af, at deres digitale løsninger er udviklet med fokus på API First. På den måde kan hvert forretningsled genbruge samme API’er til udveksle information og data mellem hinanden.

Platforme og digitale værktøjer
Mange digitale løsninger og koncepter – eksempelvis prissammenligningsværktøjer – afhænger af at kunne udveksle data med eksterne kilder. Men også platforme som Uber arbejder API First, så eksterne virksomheder/partnere at integrere deres “Book en Uber” på deres individuelle apps.

Listen er ikke fyldestgørende – og mange andre typer af virksomheder og digitale løsninger bør også have fokus på API First.