API-first: moteord eller noe du bør kreve?

API-first er et av de uttrykkene som utviklere sier med selvsagt tyngde, og som får beslutningstakere til å nikke høflig uten å vite hva de går med på. Men bak moteordet ligger en beslutning med reelle konsekvenser for budsjettet ditt og den fremtidige handlefriheten din. Det er verdt å forstå, og ofte verdt å kreve.

Hva API-first faktisk betyr

Et API er et grensesnitt som lar ulike systemer snakke med hverandre på en strukturert måte. Tenk på det som en stikkontakt: Så lenge støpselet passer, spiller det ingen rolle hva som sitter i den andre enden.

API-first betyr at systemet bygges rundt en slik stikkontakt fra begynnelsen, ikke at den bores inn i etterkant. All funksjonalitet, som å lese data, opprette poster og oppdatere informasjon, gjøres tilgjengelig via API-et fra start. Forskjellen på et slikt system og et som er bygget med «grensesnittet sist», er stor: I sistnevnte tilfelle er innmaten ofte knyttet sammen på en måte som gjør hver nye kobling til en operasjon, mens et API-first-system er laget for at andre skal kunne koble seg til.

Konkrete konsekvenser for deg

Dette høres teknisk ut, men følgene er forretningsmessige tvers igjennom. Tre av dem merkes tydeligst.

• Billigere å integrere. Når et annet system skal kobles på, for eksempel ERP-systemet, en betalingstjeneste eller et CRM, finnes veien inn allerede. Uten API-first blir hver slik kobling et eget lite utviklingsprosjekt.
• Enklere å videreutvikle. Vil du senere legge en mobilapp oppå den eksisterende tjenesten din, kan den snakke med det samme API-et som alt annet. Du bygger videre på det som finnes, i stedet for å bygge om kjernen.
• Lettere å bytte ut deler. Når grensesnittene er tydelige, kan én del av systemet erstattes uten at alt annet raser sammen. Det reduserer risikoen for innlåsing.

Et konkret eksempel: En virksomhet har en nettjeneste og vil lansere en app etter et år. Er tjenesten bygget API-first, kan appen koble seg på det eksisterende API-et og gjenbruke logikken som allerede finnes, en forholdsvis rask jobb. Er den ikke det, kan det samme ønsket bety at store deler må bygges om for i det hele tatt å kunne nås utenfra. Samme forretningsønske, helt ulik prislapp, og forskjellen ble avgjort av et teknisk valg som ble tatt lenge før.

Slik krever du det uten å detaljstyre

Du trenger ikke å kunne teknologien for å stille de riktige kravene. Trikset er å beskrive resultatet du ønsker, ikke hvordan leverandøren skal bygge. Overlat løsningen til dem, men vær tydelig på egenskapen.

I en anskaffelse eller en kravspesifikasjon kan det lyde slik: Systemet skal ha et dokumentert API som eksponerer systemets funksjoner; dere skal kunne både lese og skrive egne data via API-et; og tredjeparter skal kunne integrere mot systemet uten at kjernen må bygges om. Det styrer mot riktig egenskap uten at du må gå inn i tekniske detaljer.

Poenget er å flytte spørsmålet fra «hvilken teknologi bruker dere?» til «hva skal jeg kunne gjøre med systemet etterpå?». Det andre spørsmålet kan hvem som helst stille, og det er det som betyr noe.

Varseltegn på et lukket system

Like viktig som å formulere kravet er å kjenne igjen når svaret ikke lever opp til det. Noen signaler i svaret fra en leverandør avslører et system som er lukket i praksis, uansett hvordan det markedsføres.

Vær på vakt hvis du får vage svar på hvordan dataene dine kommer ut av systemet, eller hvis hver tenkelige integrasjon beskrives som noe som krever særskilt konsulentbistand og et eget tilbud. Et annet tegn er at alt må gå gjennom leverandørens egne grensesnitt, og at det ikke finnes noen dokumentasjon for et åpent API. Da er sannsynligheten stor for at du kjøper deg inn i et lukket system. Neste gang du vil koble på noe, sitter du da i en dyr forhandling i stedet for foran en ferdig stikkontakt.

Hos Weapp bygger vi gjerne med åpne grensesnitt fra start, nettopp for at du skal beholde friheten til å vokse og koble på nye deler. Vil du vite mer om hvordan vi tenker rundt integrasjoner? Les om tjenestene våre, eller ta kontakt med en kort beskrivelse av hva du vil bygge.