API-udvikling går sjældent galt i selve koden. Det går galt, når ingen har besluttet, hvem der ejer data, hvad der sker når modtageren er nede, og hvordan man ændrer noget uden at vælte et system, man ikke selv styrer. Her er de beslutninger, der afgør, om integrationen stadig virker om tre år.
Hovedpunkter
- Beslut ejerskab af data først. Uden det bliver hver fejl en diskussion om, hvis skyld det er.
- Design efter, hvad modtageren skal bruge — ikke efter hvordan jeres database tilfældigvis ser ud.
- Versionér fra første udgivelse. At tilføje versionering bagefter er langt dyrere.
- Antag at alt går ned. Timeouts, gentagelser og en kø er ikke luksus, det er grundudstyr.
- Log nok til at kunne genskabe et forløb uden at ringe til udvikleren.
- Dokumentation, der genereres fra koden, er den eneste slags, der forbliver rigtig.
De beslutninger, der skal træffes før koden
Fire spørgsmål afgør det meste. Hvem ejer posten, når to systemer har den? Er opdateringen realtid eller batch, og hvad er konsekvensen af et minuts forsinkelse? Hvad sker der, når modtageren afviser noget — fejler hele overførslen, eller lægges posten til side? Og hvem opdager det?
Bliver de fire besvaret på forhånd, er resten almindeligt håndværk. Bliver de ikke, betaler I for dem senere, typisk mens noget er i stykker i produktion.
REST, GraphQL eller beskeder
REST passer til de fleste integrationer mellem systemer. Det er forudsigeligt, let at cache og let at fejlsøge med almindelige værktøjer.
GraphQL giver mening, når mange forskellige klienter har brug for forskellige udsnit af de samme data — typisk apps og frontends, hvor antallet af kald ellers eksploderer.
Beskeder og køer er svaret, når afsenderen ikke må vente på modtageren. Ordrer, fakturaer og lagerbevægelser hører oftest til her, fordi de skal frem, også når det andet system er nede.
De fleste virksomheder ender med alle tre. Pointen er at vælge bevidst per integration frem for at lade den første beslutning gælde for evigt.
Versionering og ændringer
I det øjeblik en anden virksomhed kalder jeres API, kan I ikke længere ændre frit. Læg versionen i stien fra starten, og gør det til en regel, at felter kan tilføjes, men aldrig fjernes eller omdøbes i samme version.
Skal noget udgå, så meld det som udgået, log hvem der stadig bruger det, og kontakt dem. Uden det log gætter I, og gætterier bliver til nedetid hos en kunde.
Sikkerhed, i den rækkefølge der betaler sig
- Autentificering per klient. Én nøgle delt af alle betyder, at ingen kan lukkes ned uden at lukke alle.
- Rate limiting. Beskytter mod både angreb og en klient med en løbsk løkke.
- Validering af input. Antag aldrig, at afsenderen sender det aftalte.
- Kun de felter, der skal bruges. Den hyppigste datalækage er et endpoint, der returnerer hele objektet.
Når integrationen rammer et ældre system
Det er her, de fleste timer forsvinder. Ældre systemer har sjældent et API, ofte ingen dokumentation, og næsten altid felter, der bruges til noget andet end deres navn antyder.
Regn med en afdækningsfase, før nogen estimerer selve arbejdet. Skal datalaget også ryddes op undervejs, hører det under databaseudvikling, og skal det gamle system fortsat køre imens, under softwarevedligeholdelse.
Drift efter lanceringen
En integration er aldrig færdig. Certifikater udløber, modtagere ændrer felter, datamængder vokser. Aftal fra start, hvem der kigger på fejlloggen, hvor hurtigt der reageres, og hvordan en fejlet post køres igennem igen.
Vi bygger den slags som en del af vores API-udviklingstjenester, oftest sammen med applikationsudvikling, og med et dedikeret udviklingsteam, når integrationerne skal vedligeholdes over tid.
Ofte stillede spørgsmål
To til seks uger, når begge sider har et dokumenteret API. Mangler den ene side dokumentation, er afdækningen ofte længere end selve udviklingen.
En platform betaler sig ved mange ensartede integrationer. Ved en håndfuld specifikke er den et abonnement oveni, og I skal stadig skrive logikken. Tæl integrationerne, før I beslutter.
Vælg batch, medmindre nogen kan beskrive, hvad et minuts forsinkelse konkret koster. Batch er enklere, billigere at drive og langt lettere at køre om efter en fejl.
Bed om et testmiljø, og accepter ikke “test mod produktion” som svar. Findes der intet testmiljø, så byg en simulator ud fra dokumentationen — det er billigere end den første fejl i produktion.
Inden I beslutter
Afklar ejerskab af data, realtid mod batch, og hvad der sker ved fejl — før nogen skriver kode. Versionér fra dag ét, log nok til at kunne svare kunden, og aftal hvem der kigger på fejlene om et år.
Skal vi se på jeres integrationer? Skriv til os eller book et møde.
