API redo för publicering

Organisationer har sällan möjlighet att skapa API:er som kan betraktas som fulländade direkt, utan behöver jobba med dem över tid för att göra dem mer mogna. Ett API:s mognadsnivå kan mätas på flera sätt. Det finns vissa mått av teknisk mognadsgrad för ett specifikt API, medan man kan se bredare på organisationers mognadsgrad i hur de jobbar med API management. Det går också att titta på mognadsgrad gällande API:ers säkerhet.

Baslinjen

Hur kan organisationer hitta arbetssätt att jobba med sina API:er för att nå en basnivå för t.ex. design, teknik, funktionalitet, tillgänglighet och säkerhet, för att senare hitta områden där mer arbete krävs för att komma längre i API:ets fulländning?

Första versionen

Genom att få en överblick över olika delar av organisationens arbete med API:er så kan riktade insatser göras för att gå mot en högre mognadsgrad inom ett eller flera områden. Genom att sträva efter att komma upp till en baslinje så kan organisationen känna sig bekväm med att publicera en första version av API:et, för att sedan planera insatser för att nå längre inom de olika områdena.

Modellerna

För att känna sig trygg med att publicera sitt första, eller senaste, API så finns behov av att känna att man gjort tillräckligt för att kunna publicera det. Allt är kanske inte perfekt, men att det är tillräckligt bra för att kunna erbjudas till konsumenter för nyttjande och det går att jobba vidare för att förbättra det senare. För att uppnå denna känsla så kan organisationer eftersträva att nå följande baslinje inom områdena API implementation, data-abstraktion samt API säkerhet som visualiseras i bilden nedan.

Visualisering av modeller och mognadsnivåer inom områdena API implementation, data-abstraktion samt API säkerhet.

Modellerna i bilden hanterar alla olika områden inom API hantering. Det handlar om API implementation, Data-abstraktion och API säkerhet. Varje område har olika nivåer där mognad kan mätas. Baslinjen i dessa områden ligger på nivå 2. Modellerna och dess nivåer beskrivs mer i detalj på sidan.

Rickardsons Maturity Model

I den första kolumnen ser vi Richardsons Maturity model som visar hur pass mogen ett API är gentemot arkitekturstilen REST, och längre bort från RPC stilenÖppnas i ny flik, i och med klättring i mognadsgrad.

Nivå	Scope	Beskrivning
3	HATEOAS	Införande av Hypermedia länkade data (HATEOAS, Hypermedia as the Engine of Application State) leder till att API kan betraktas som fullvärdigt REST API
2	HTTP	HTTP semantiken efterföljs i stort men möjligheten att navigera med hjälp av hypermedia-teknik saknas. Det innebär att konsumenten inte kan anropa API utan tidigare kunskap om API:et
1	Resurser	Konsumenten kan använda API med hjälp av resurser, som dock inte jobbar med korrekt semantik enligt HTTP protokollet (exempelvis använder metoder och felkoder felaktigt). Detta leder till försämrad prestanda och missade skalbarhetfördelar.
0		API består av en endpoint, där konsumenten istället skickar parametrar för att utföra olika begäran

Organisationer skall nå nivå 2 för att nå baslinjen, men bör sedan eftersträva att nå nivå 3 för att nå API:ets fulla potential.

Amundsens Maturity Model

Den andra tabellen visar Amundsens Maturity Model. Den beskriver API:ets förmåga att abstrahera sin datamodell. Desto högre nivå ett API når i modellen, desto mer frikopplat är API:et från de interna modellerna.

Nivå	Scope	Beskrivning
3	Utförandecentrisk	Datamodell jobbar med de funktioner som API avser att stödja. Konsumenten presenteras en datamodell som också visar möjliga funktioner som är möjliga utan att behöva se över dokumentationen.
2	Resurscentrisk	Konsumenten kan nu jobba mot HTTP metoder, där datamodellen är lyft externt och exponerar data skilt från interna modeller.
1	Objektcentrisk	Den datamodell som exponeras mot konsumenten är representerad i implementationsobjekt, istället för nere i databasen, men fortfarande dock som intern modell. Detta sköts ofta i middleware produkter.
0	Databascentrisk	Den datamodell som används i databasen reflekteras direkt i API:et. Detta innebär att det saknas abstraktionsnivå och förändringar i databasstrukturen slår direkt mot konsumenten.

Organisationer skall nå nivå 2 för att nå sin baslinje, men bör sedan eftersträva att nå nivå 3 för att interna och externa datamodeller ska kunna frikoppla sig från varandra.