När datamodellen är färdig kan man utifrån den ta fram ett utkast till ett eller flera programmeringsgränssnitt. Ett utkast till programmeringsgränssnittet kan omfatta en enkel datamodell i sin helhet eller delar av en mer komplicerad modell.
Uppdaterad: 6.5.2026
Vad är modellen API först?
API först (API First) är en utvecklingsstrategi där man planerar programmeringsgränssnittet (API) före man gör själva programmeringsarbetet. Detta säkerställer att programmeringsgränssnittet utgör grunden för hela informationssystemet, så att de övriga delarna byggs upp kring det. En tydlig specifikation i början underlättar informationssystemens interoperabilitet och möjliggör att olika utvecklingsteam arbetar parallellt i genomförandefasen som följer efter specifikationen.
API först-modellen är nyttig särskilt vid komplicerade anskaffningar, eftersom den delar upp helheten i hanterbara delar. På så sätt kan olika team utveckla sina egna delar samtidigt.
Hos Amazon innebär API först-metoden att man före utveckling av nya applikationer, tjänster eller produkter först planerar planritningarna för de programmeringsgränssnitt som dessa använder. Detta säkerställer att alla nya informationssystem och tjänster är interoperabla, flexibla och enkla att integrera i andra informationssystem.
Amazons grundare Jeff Bezos presenterade API först-modellen år 2002:
Alla data och behandlingen av data sker med hjälp av programmeringsgränssnitt.
Teamen samarbetar via programmeringsgränssnitt.
Tekniken för genomförandet är sekundär, programmeringsspråket kan väljas fritt.
Alla programmeringsgränssnitt ska vara externt tillgängliga.
Uppdaterad: 6.5.2026
Fördelar med API först-modellen
Fördelar med API först-modellen:
Kompatibilitet: Programmeringsgränssnittet specificeras först, vilket underlättar samarbetet mellan informationssystemen.
Smidig utveckling: Teamen kan arbeta samtidigt och projektet därmed fortskrida snabbare.
Skalbarhet: Det är lättare att bygga ut och underhålla informationssystemen.
Med denna metod återstår bara genomförandet, eftersom utkastet till programmeringsgränssnittet kan användas för att samla in respons redan före själva programmeringsarbetet. Intressentgrupper inom och utanför organisationen kan kommentera gränssnittsbeskrivningarna.
Många kostnadsfria och kommersiella verktyg för API-hanteringen är utformade för att stöda API först-modellen, vilket gör det enkelt att genomföra modellen. Med de flesta verktygen kan en stor del av programkoden skapas automatiskt utifrån beskrivningen av programmeringsgränssnittet, vilket minskar det återstående programmeringsarbetet avsevärt. Samtidigt minskar antalet fel.
API först-modellen kan jämföras med stadsplanering. Först kommer man överens om byggplatser och infrastruktur, varefter teamen bygger sina egna ”hus” enligt reglerna. I RESTful-arkitekturen planeras systemet genom att först specificera den information som ska behandlas och därefter OpenAPI-beskrivningarna. När dessa är färdiga går man vidare till programmeringsarbetet.
Mikko Pitkänen, direktör för Myndigheten för digitalisering och befolkningsdata, lyfter fram de omfattande fördelarna som kan uppnås:
När programmeringsgränssnittsförmågan ökar, ökar också förmågan att reagera på och integreras i en föränderlig verksamhetsmiljö betydligt. En gränssnittsbaserad verksamhetsmodell som organisationen godkänt fungerar som en naturlig utgångspunkt även för planeringen av dess viktigaste objekt.
API först-modellen är särskilt användbar i situationer med många leverantörer. Programmeringsgränssnitten utgör en karta över de viktigaste tjänsterna. Samtidigt är de löften till olika utvecklingsteam om vad som kommer att göras och hur arbetet som gjorts kan utnyttjas i andra delar.
Enligt Ville Peltola, chef för artificiell intelligens och data vid Teknologiateollisuus ry, kan metoden där man börjar med programmeringsgränssnitten bidra till att det uppstår en ny kultur för gemensam utveckling:
API först-modellen är ägnad att förändra utvecklingskulturen och skapar en bra grogrund för nya tjänster i branschen, som kan uppstå i ekosystemet även på initiativ av medborgare, organisationer eller företag.
Skatteförvaltningen kan ge ett praktiskt exempel på API först-modellen inom den offentliga förvaltningen.
Det har varit förvånansvärt lätt för substansexperterna att skapa specifikationer av datainnehållet och OpenAPI-beskrivningar i samarbete med API-teamet.
– Mika Hyyrynen, ledare av Skatteförvaltningens API-team.
Uppdaterad: 6.5.2026
Undvik ”on demand”-modellen
När anskaffningen görs endast för en organisation kan det hända att programmeringsgränssnitten glöms bort. I anskaffningsskedet förstår man inte nödvändigtvis behovet av att överföra information in i och ut ur informationssystemet.
Ett program som levereras nyckelfärdigt kan innehålla allting, förutom de gränssnitt som kommer att behövas i framtiden för att förbättra arbetseffektiviteten och produktiviteten. Programvarans datamodeller kan också vara skyddade med industriella rättsskydd, vilket gör att det kan vara dyrt eller till och med omöjligt att lägga till ett programmeringsgränssnitt.
Motsatsen till API först-modellen är on demand-modellen, där programmeringsgränssnitten genomförs först när de behövs. Om man inte förstår programmeringsgränssnittens betydelse från början, undviker man att genomföra dem och betraktar dem endast som tekniska lösningar.
On demand-modellens svagheter
Man går miste om den smidighet som utvecklingsarbetet och programmeringsgränssnittet för med sig.
Den fortsatt utvecklingen och fortsatta konkurrensutsättningar är svårare att genomföra.
Resulterar lätt i extra arbete och användning av tillfälliga lösningar.
Omdatamodellerna (inkl. kodsystem och ordlistor) inte har beskrivits och planerats som interoperabla, måste de beskrivas. Utan planerad semantisk interoperabilitet kan varje informationssystem eller applikation ha en egen datamodell. Dessa egna datamodeller är i allmänhet inte kompatibla med andra informationssystem. Detta ökar arbetsmängden, varvid fördelarna med programmeringsgränssnitten minskar.
Syftet med programmeringsgränssnitten är att skapa smidighet och flexibilitet i genomförandet. Med hjälp av dem kan informationssystemets olika delar utvecklas och byggas ut kostnadseffektivt utan onödig komplexitet.
I on demand-modellen måste programmeringsgränssnittet ofta göras två gånger:
på ett icke-standardiserat sätt utan dokumentation eller hanteringsverktyg
på nytt senare fram när ett externt behov tvingar till ett bättre genomförande.