API-first – modeord eller något du bör kräva?

API-first är ett av de där uttrycken som utvecklare säger med självklar tyngd och som får beslutsfattare att nicka artigt utan att veta vad de går med på. Men bakom modeordet finns ett beslut med verkliga konsekvenser för din budget och din framtida rörelsefrihet. Det är värt att förstå – och ofta värt att kräva.

Vad API-first faktiskt betyder

Ett API är ett gränssnitt som låter olika system prata med varandra på ett strukturerat sätt. Tänk på det som en kontaktdosa: så länge kontakten passar spelar det ingen roll vad som sitter i andra änden.

API-first betyder att systemet byggs kring en sådan kontaktdosa från början, inte att den borras in i efterhand. All funktionalitet – att läsa data, skapa poster, uppdatera information – görs åtkomlig via API:et redan från start. Skillnaden mot ett system som byggts “gränssnitt sist” är stor: i det senare fallet är innanmätet ofta hopknutet på ett sätt som gör varje ny koppling till en operation, medan ett API-first-system är gjort för att andra ska kunna ansluta.

Konkreta konsekvenser för dig

Det här låter tekniskt, men följderna är rakt igenom affärsmässiga. Tre av dem märks tydligast.

• Billigare att integrera. När ett annat system ska kopplas på – affärssystemet, en betaltjänst, ett CRM – finns redan vägen in. Utan API-first blir varje sådan koppling ett eget litet byggprojekt.
• Enklare att bygga vidare. Vill du senare lägga en mobilapp ovanpå din befintliga tjänst kan den prata med samma API som allt annat. Du bygger ovanpå det som finns i stället för att bygga om kärnan.
• Lättare att byta ut delar. När gränssnitten är tydliga kan en del av systemet ersättas utan att allt annat rasar. Det minskar risken för inlåsning.

Ett konkret exempel: ett bolag har en webbtjänst och vill efter ett år lansera en app. Är tjänsten byggd API-first kan appen koppla på det befintliga API:et och återanvända logiken som redan finns – en jämförelsevis snabb insats. Är den det inte, kan samma önskemål innebära att stora delar måste byggas om för att över huvud taget gå att nå utifrån. Samma affärsönskan, helt olika prislapp, och skillnaden avgjordes av ett tekniskt val som gjordes långt tidigare.

Så kräver du det utan att detaljstyra

Du behöver inte kunna tekniken för att ställa rätt krav. Tricket är att beskriva utfallet du vill ha, inte hur leverantören ska bygga. Överlåt lösningen till dem, men var tydlig med egenskapen.

I en upphandling eller kravbild kan det låta så här: systemet ska ha ett dokumenterat API som exponerar dess funktioner; er data ska gå att både läsa och skriva via det API:et; och tredjepart ska kunna integrera mot systemet utan att kärnan behöver byggas om. Det styr mot rätt egenskap utan att du behöver gå in i teknisk detalj.

Poängen är att flytta frågan från “vilken teknik använder ni?” till “vad ska jag kunna göra med systemet sedan?”. Den andra frågan kan vem som helst ställa, och den är den som spelar roll.

Varningstecken på ett stängt system

Lika viktigt som att formulera kravet är att känna igen när svaret inte lever upp till det. Vissa signaler i en leverantörs svar avslöjar ett system som är stängt i praktiken, oavsett hur det marknadsförs.

Var vaksam om du får svävande svar på hur din data kommer ut ur systemet, eller om varje tänkbar integration beskrivs som något som kräver särskild konsultation och offert för sig. Ett annat tecken är att allt måste gå genom leverantörens egna gränssnitt och att det inte finns någon dokumentation för ett öppet API. Då är sannolikheten stor att du köper in dig i ett slutet system – och att nästa gång du vill koppla på något, sitter du i en dyr förhandling snarare än vid en färdig kontaktdosa.

Vi på Weapp bygger gärna med öppna gränssnitt från start, just för att du ska behålla friheten att växa och koppla på nya delar. Vill du veta mer om hur vi tänker kring integrationer? Läs om våra tjänster eller hör av dig med en kort beskrivning av vad du vill bygga.