Rigtig mange af de apps vi udvikler bygger på en variation af følgende tekniske arkitektur:
- En eksisterende server-komponent har værdifulde data
- For at kunne eksponere data fra server-komponenten, udvikles der et API
- App’en henter data via API’et og viser disse på mobiltelefonen – gerne på en ny og frisk måde
- Ofte kombineres data fra server-komponenten med andre data eller andre services, så der skabes en helt ny service tilpasset en mobil kontekst
I mange af disse projekter skal API’et udvikles eller der eksisterer allerede et halvfærdigt API, som skal justeres og gøres klart.
Udviklingen eller opdateringen af API’et gøres alt for ofte til et rent teknisk spørgsmål – skal API’et laves som REST eller SOAP? Skal det anvende JSON eller XML? Disse spørgsmål er bestemt relevante og vigtige.
Men, de vigtige spørgsmål om hvilke forretningsmuligheder API’et kan åbne op for, hvordan laves API’et på en måde så det reelt kan genbruges stilles ofte ikke.
Min erfaring er, at der spildes mange penge og mange muligheder, fordi der laves dårlige, ikke-gennemtænkte og ikke-dokumenterede API’er. Fordi det er svært for ikke-teknikere at tjekke et API og svært at forstå det, så overlades API’et fuldstændigt til teknikere. Og fordi det mærkeligt nok tit er lav-status at udvikle API’er, så er det ofte ”den nye mand” eller junior-udviklere der laver API-opgaverne. Resultatet er dårlig kvalitet, manglende forretningsforståelse og spild af forretningsmuligheder.
Det lyder måske banalt – men min erfaring er, at API’et både nedprioriteres og at dets reelle værdi ikke forståes. Der er selvfølgelig undtagelser – men vi ser fere dårlige API’er end gode.
