API-first: modeord eller noget du bør kræve?

API-first er et af de udtryk som udviklere siger med største selvfølgelighed, og som får beslutningstagere til at nikke høfligt uden at vide hvad de går med til. Men bag modeordet ligger en beslutning med reelle konsekvenser for dit budget og din fremtidige handlefrihed. Det er værd at forstå, og ofte værd at kræve.

Hvad API-first egentlig betyder

Et API er en grænseflade der lader forskellige systemer tale sammen på en struktureret måde. Tænk på det som en stikkontakt: Så længe stikket passer, er det ligegyldigt hvad der sidder i den anden ende.

API-first betyder at systemet bygges omkring sådan en stikkontakt fra begyndelsen, ikke at den bores ind bagefter. Al funktionalitet, altså at læse data, oprette poster og opdatere information, gøres tilgængelig via API’et fra start. Forskellen i forhold til et system der er bygget med “grænsefladen til sidst”, er stor: I det sidstnævnte tilfælde er indmaden ofte viklet sammen på en måde der gør hver ny kobling til en operation mens et API-first-system er lavet til at andre kan koble sig på.

Konkrete konsekvenser for dig

Det lyder teknisk, men følgerne er forretningsmæssige hele vejen igennem. Tre af dem mærkes tydeligst.

• Billigere at integrere. Når et andet system skal kobles på, f.eks. ERP-systemet, en betalingstjeneste eller et CRM, er vejen ind der allerede. Uden API-first bliver hver sådan kobling sit eget lille byggeprojekt.
• Nemmere at bygge videre. Vil du senere lægge en mobilapp oven på din eksisterende tjeneste, kan den tale med samme API som alt andet. Du bygger oven på det der findes, i stedet for at bygge kernen om.
• Lettere at udskifte dele. Når grænsefladerne er tydelige, kan en del af systemet erstattes uden at alt andet styrter sammen. Det mindsker risikoen for lock-in.

Et konkret eksempel: En virksomhed har en webtjeneste og vil efter et år lancere en app. Er tjenesten bygget API-first, kan appen koble sig på det eksisterende API og genbruge den logik der allerede findes, hvilket er en forholdsvis hurtig indsats. Er den ikke det, kan samme ønske betyde at store dele skal bygges om for overhovedet at kunne nås udefra. Samme forretningsønske, helt forskellig pris, og forskellen blev afgjort af et teknisk valg der blev truffet længe før.

Sådan kræver du det uden at detailstyre

Du behøver ikke at kunne teknikken for at stille de rigtige krav. Tricket er at beskrive det resultat du vil have, ikke hvordan leverandøren skal bygge. Overlad løsningen til dem, men vær tydelig om egenskaben.

I et udbud eller en kravspecifikation kan det lyde sådan her: Systemet skal have et dokumenteret API der eksponerer dets funktioner; jeres data skal både kunne læses og skrives via det API; og tredjepart skal kunne integrere med systemet uden at kernen skal bygges om. Det styrer mod den rigtige egenskab uden at du behøver at gå i teknisk detalje.

Pointen er at flytte spørgsmålet fra “hvilken teknologi bruger I?” til “hvad skal jeg kunne gøre med systemet bagefter?”. Det andet spørgsmål kan alle stille, og det er det der betyder noget.

Advarselstegn på et lukket system

Lige så vigtigt som at formulere kravet er det at genkende når svaret ikke lever op til det. Visse signaler i en leverandørs svar afslører et system der i praksis er lukket, uanset hvordan det markedsføres.

Vær på vagt hvis du får vage svar på hvordan dine data kommer ud af systemet, eller hvis enhver tænkelig integration beskrives som noget der kræver særskilt konsulentbistand og et tilbud for sig. Et andet tegn er at alt skal gå gennem leverandørens egne grænseflader, og at der ikke findes nogen dokumentation for et åbent API. Så er sandsynligheden stor for at du køber dig ind i et lukket system, og for at du, næste gang du vil koble noget på, sidder i en dyr forhandling snarere end ved en færdig stikkontakt.

Vi hos Weapp bygger gerne med åbne grænseflader fra start, netop for at du kan beholde friheden til at vokse og koble nye dele på. Vil du vide mere om hvordan vi tænker integrationer? Læs om vores ydelser eller kontakt os med en kort beskrivelse af hvad du vil bygge.