Hvordan sikre lesbar og vedlikeholdbar kodestruktur med betingelser i Kotlin

Betingelseslogikk i programmering er et fundamentalt verktøy for å kontrollere flyten av et program. I mange tilfeller er det behov for å gjøre valg mellom flere alternativer avhengig av gitte betingelser. I Kotlin kan dette gjøres med if-else, som er et av de mest brukte kontrollstrukturene. Når det håndteres på riktig måte, kan betingelseslogikk gjøre koden både mer lesbar og vedlikeholdbar, samt sørge for at bare den nødvendige koden kjører under spesifikke forhold.

Erklæringsform for If-Else

Når sideeffekter utføres direkte i hver gren, er det hensiktsmessig å bruke if-else som en erklæring. For eksempel:

kotlin
Copy code
if (tasks.isEmpty()) {
    println("Ingen oppgaver tilgjengelig.")
} else {
    println("Du har ${tasks.size} oppgaver.")
}

I dette eksemplet kjører vi en av to println-kall basert på en betingelse, men vi returnerer ingen verdi. Denne formen er enkel, men kan føre til gjentatte I/O-kall og kan være vanskelig å teste enhetlig.

Uttrykksform for If-Else

Når if-else brukes som et uttrykk, kan det returnere en verdi. Dette skiller beslutningslogikk fra sideeffekter og gjør det lettere å håndtere logikk på en ryddig måte. Eksempelet under:

kotlin
Copy code
val message = if (tasks.isEmpty()) {

    "Ingen oppgaver tilgjengelig."
} else {
    "Du har ${tasks.size} oppgaver."
}
println(message)

Her beregner vi først meldingen, og skriver den ut bare én gang. Dette reduserer duplisering og gjør hensikten bak koden klarere. Ved å isolere beslutningslogikken på denne måten, kan vi gjøre den lettere å teste enhetlig.

Chaining Conditions med Else-If

Når flere eksklusive sjekker er nødvendige — for eksempel for å håndheve en maksimum oppgavegrense eller validere lengden på en beskrivelse — kan det være nyttig å kjede else-if. Dette gir en ryddigere måte å håndtere flere betingelser på, som i eksempelet nedenfor:

kotlin
Copy code
if (tasks.size >= maxTasks) {
    println("Kan ikke legge til flere oppgaver: grensen er nådd.")
} else if (desc.isBlank() || desc.length > 50) {
    println("Beskrivelsen må være mellom 1 og 50 tegn.")
} else {
    tasks[nextId] = desc
    println("Oppgave lagt til: $nextId")
    nextId++
}

Fordelene med dette mønsteret er flere: betingelsene evalueres i rekkefølge, tidlige grener forhindrer unødvendige sjekker, og obligatoriske krøllparenteser gjør koden mer lesbar.

Tidlig Utkast med Elvis-operatoren

I stedet for små if-else-blokker for å sjekke null, kan Elvis-operatoren (?:) benyttes for å gjøre nullsjekker mer konsise. I vårt REPL-loop kan vi for eksempel bruke:

kotlin
Copy code
val line = readLine()?.trim() ?: return // avslutt ved EOF eller null

Denne ene linjen erstatter et langt if-else-blokk og gir bedre kontroll over flyten samtidig som koden blir mer kompakt.

Bruk av “When”-uttrykk

Ettersom antall betingelser øker, kan en rekke if-else-betingelser raskt bli uoversiktlige og vanskelige å vedlikeholde. Kotlin gir oss "when"-uttrykket, som gir en renere og mer vedlikeholdbar måte å håndtere betingelser på. Dette uttrykket fungerer som et mønster-matching alternativ, der vi kan tilknytte spesifikke betingelser til handlinger.

kotlin
Copy code
when {

    input.startsWith("add ") -> handleAdd(input.drop(4))
    input == "list" -> handleList()
    input.startsWith("remove ") -> handleRemove(input.drop(7).toIntOrNull())
    input == "exit" -> return
    else -> println("Ukjent kommando")
}

Med "when"-uttrykket kan vi eliminere lange kjeder av if-else-setninger og gjøre koden mye mer lesbar og strukturert.

Erstatte If-Else-kjeder med “When”

Som et eksempel på hvordan vi kan bruke "when" til å erstatte flere betingelser, kan vi bruke følgende kode for å håndtere ulike kommandoer:

kotlin
Copy code
when (command) {
    "add" -> handleAdd(args)
    "list" -> handleList()
    "remove" -> handleRemove(args.toIntOrNull())
    "stats" -> handleStats()
    else -> println("Ukjent kommando: $command")
}

Her unngår vi repetisjon av input ==, og fokuserer heller på variabelen som skal sendes til de ulike handlingene.

Mønster matching og Type-sjekk med “When”

I Kotlin kan vi bruke "when" for mer enn bare enkel likhetsprøving. Vi kan utføre type-sjekker, sjekke mot intervaller eller bruke samlinger av verdier. For eksempel:

kotlin
Copy code
when (val id = args.toIntOrNull()) {

    null -> println("Ugyldig ID-format")
    in 1..tasks.size -> handleRemove(id)
    else -> println("ID er utenfor rekkevidde")
}

Dette er et effektivt verktøy for å håndtere forskjellige tilfeller i programmet, og gir en mye mer ryddig struktur enn å bruke flere if-else-setninger.

Sealed Klasser og Exhaustive “When”

Når vi modellerer kommandoer som sealed interfaces, sørger "when"-uttrykket for at vi håndterer hver subtype eksplisitt, og at ingen mulige tilfeller blir utelatt. Dette gir et ekstra lag med sikkerhet i programmet, hvor alle mulige scenarier blir håndtert på en robust måte.

kotlin
Copy code
sealed interface Command

data class Add(val desc: String): Command
object ListAll: Command

data class Remove(val id: Int?): Command

object Stats: Command
object Exit: Command

Ved å bruke sealed klasser kan vi sikre at alle mulige kommandoer er dekket i en "when"-struktur, noe som kan forhindre uforutsette feil.

Betingelseslogikk i Kotlin er et kraftig verktøy som kan være ekstremt effektivt når det brukes på riktig måte. Ved å bruke både if-else, when, og andre mønstre som Elvis-operatoren kan vi holde koden både kompakt og lettforståelig, samtidig som vi unngår redundans og sørger for at alle beslutningspunkter er eksplisitte, testbare og vedlikeholdbare.

Hvordan Designe Objektorienterte Konstruksjoner og Klasser i Kotlin

I objektorientert programmering er klasser de grunnleggende byggesteinene for å organisere data og funksjonalitet. Gjennom bruken av klasser kan vi effektivt gruppere relatert informasjon og operasjoner sammen, og dermed skape struktur og gjenbrukbare abstraksjoner i programvaren. I denne sammenhengen vil vi fokusere på hvordan man definerer klasser, håndterer konstruktører, og bruker forskjellige objektorienterte prinsipper for å utvikle et ryddig og utvidbart system.

Definering av Klasser og Initialisering av Egenskaper

Tidligere håndterte vi oppgaver som løse datastrukturer, for eksempel kart med integer-nøkler og tekstverdier. Imidlertid, etter hvert som behovene våre utvikler seg – for eksempel å spore prioritering, tidsstempel og fullføringsstatus – blir det nødvendig å bruke en mer strukturert tilnærming. Klasser gir oss denne strukturen ved å samle relaterte data og funksjoner.

I Kotlin kan vi enkelt definere en klasse ved å bruke en primær konstruktør. Her er et eksempel på hvordan vi kan deklarere en Task-klasse:

kotlin
Copy code
data class Task(

    val id: Int,
    val description: String,
    val highPriority: Boolean = false,
    var completed: Boolean = false,
    val createdTimestamp: Long = System.currentTimeMillis()
)

I dette eksemplet defineres flere egenskaper som id, description, highPriority, completed, og createdTimestamp. Det er viktig å merke seg at Kotlin automatisk genererer metoder som equals(), hashCode(), toString(), og copy(), takket være bruken av data-modifikatoren.

Validere Data med init-blokken

Noen ganger kan det være nødvendig å håndheve ekstra regler eller validere data ved opprettelsen av et objekt. Kotlin tilbyr en init-blokk som kjører umiddelbart etter primær konstruktør. Hvis vi for eksempel ønsker å sørge for at beskrivelsen av en oppgave ikke er tom, kan vi utvide Task-klassen som følger:

kotlin
Copy code
init {

    require(description.isNotBlank()) { "Task description cannot be blank." }
}

Med dette tillegget, hvis vi forsøker å opprette en Task med en tom beskrivelse, vil konstruktøren kaste en IllegalArgumentException med en tilpasset feilmelding. Dette flytter valideringen til selve klassen, slik at all kode som bruker Task kan stole på at instansene alltid er gyldige.

Instansiering og Håndtering av Task-Objekter

kotlin
Copy code
val tasks: MutableMap<Int, Task> = mutableMapOf()
var nextId = 1

Når vi håndterer "legg til"-kommandoer, kan vi erstatte den eksisterende map-strukturen med objekter av typen Task. I stedet for å sende løs data, kan vi nå bruke en sterkt typet oppgave, og kalle dens metoder direkte:

kotlin
Copy code
val task = Task(id = nextId, description = desc, highPriority = desc.startsWith("!"))

tasks[nextId] = task
println("Task added: $task")
nextId++

Når vi skriver ut oppgaven, vil Kotlin automatisk generere en meningsfull beskrivelse ved hjelp av toString()-metoden, noe som gir en rik innsikt i objektets tilstand.

Endre og Tilgang til Egenskaper

En av fordelene ved å bruke klasser er at vi kan endre deres tilstand på en kontrollert måte. Når brukeren markerer en oppgave som fullført, kan vi hente objektet og oppdatere den mutable egenskapen:

kotlin
Copy code
val task = tasks[id]
if (task != null) {
    task.completed = true
    println("Marked complete: $task")
}

I dette tilfellet kan vi bruke den mutable completed-egenskapen til å endre oppgavens tilstand uten å måtte opprette et nytt objekt. Siden vi jobber med objektet direkte, ser alle referanser til oppgaven de oppdaterte verdiene umiddelbart.

Sekundære Konstruktører for Komplekse Opprettelser

Et eksempel på en sekundær konstruktør er å opprette en høyprioritert oppgave hvis beskrivelsen starter med et utropstegn (!). Denne logikken kan implementeres som følger:

kotlin
Copy code
data class Task(
    val id: Int,
    val description: String,
    val highPriority: Boolean = false,
    var completed: Boolean = false,
    val createdTimestamp: Long = System.currentTimeMillis()
) {
    // Sekundær konstruktør
    constructor(id: Int, rawDescription: String) : this(
        id = id,
        description = rawDescription.trimStart('!'),
        highPriority = rawDescription.startsWith("!")
    )
}

Viktige Prinsipper og Utvidelser

Når vi bygger objektorienterte systemer, er det avgjørende å tenke på designprinsipper som arv, grensesnitt og innkapsling. Ved å bruke klasser på en strukturert måte kan vi dele atferd mellom objekter gjennom abstrakte basisklasser og grensesnitt, samtidig som vi holder implementasjonen isolert og sikker. I tillegg kan synlighetsmodifikatorer som private, internal og public hjelpe til med å skjule implementasjonsdetaljer og bare eksponere stabile, offentlige API-er.

I et godt design er det viktig å vurdere fremtidige utvidelser og gjøre systemet så utvidbart som mulig. Ved å bruke objektorienterte prinsipper kan vi legge til nye funksjoner uten å endre eksisterende kode, og dermed gjøre vedlikehold og videreutvikling enklere over tid.

Hvordan håndtere applikasjonsstatus og oppførsel i moderne applikasjoner

I utviklingen av applikasjoner er en viktig utfordring å organisere og spore tilstanden, samt å oppdatere denne på en forutsigbar måte. Når vi jobber med applikasjoner som skal håndtere en rekke oppgaver, som for eksempel en Task Tracker, er det essensielt å ha en strukturert tilnærming til hvordan tilstanden (state) representeres, hvordan den kan endres, og hvordan vi kan sikre at applikasjonen reagerer korrekt på disse endringene.

En av de mest effektive metodene for å håndtere tilstand i applikasjoner er bruken av immutable data classes og muterbare containere som er begrenset til bestemte deler av systemet. Denne tilnærmingen hjelper oss å beskytte applikasjonen mot utilsiktede feil og gjør den mer prediktiv og stabil. Når vi ser på hvordan applikasjonen skal håndtere oppgavene sine, må vi skille mellom data som er konstant og ikke kan endres, og data som er dynamisk og kan endres.

I Kotlin, for eksempel, er dataklasser (data classes) et utmerket verktøy for å representere uforanderlige tilstander. Når vi skaper en instans av en dataklasse, vil dens val-egenskaper aldri kunne endres. Dette gjelder spesielt for objektet som representerer en oppgave, der egenskaper som ID, beskrivelse og opprettelsestidspunkt forblir konstante. En oppgave kan derimot ha en variabel egenskap som markerer om oppgaven er fullført, og for å endre denne tilstanden kan vi lage en ny instans av oppgaven ved hjelp av copy()-metoden. På denne måten sørger vi for at originalen forblir uforandret, og vi oppretter en ny tilstand uten å forstyrre andre deler av applikasjonen.

For eksempel, når vi markerer en oppgave som fullført, kan vi gjøre det slik:

kotlin
Copy code
fun markComplete(id: Int) {

    val old = tasks[id] ?: return
    val updated = old.copy(completed = true)
    tasks[id] = updated
}

Her behandler vi oppgavene som uforanderlige objekter, og bruker en mutable map for å oppdatere tilstanden på en kontrollert måte. Denne metoden hindrer utilsiktede bivirkninger i funksjoner som bare leser dataene. Når vi trenger å vise hele tilstanden, kan vi ta en kopi av kartet, som gir oss en sikker og lesbar visning av dataene:

kotlin
Copy code
fun snapshotTasks(): Map<Int, Task> = tasks.toMap()

På den andre siden har vi noen deler av applikasjonen hvor vi faktisk trenger ekte mutabilitet, for eksempel telleverdier eller flagg som kan endres over tid. I slike tilfeller kan vi bruke variabler (var) og muterbare samlinger som MutableList, MutableMap og MutableSet. Dette kan være nyttig for å opprettholde en genererende ID for oppgaver eller for å oppdatere oppgavene i den rekkefølgen de ble lagt til.

For eksempel:

kotlin
Copy code
val id = nextId++
tasks[id] = Task(id, desc)
insertionOrder.add(id)

En annen viktig teknikk i applikasjonsutvikling er tilstanden for applikasjonen som helhet. Ofte kan applikasjonen operere i forskjellige tilstander, for eksempel når den er "kjørende", "kun lesing", eller i "vedlikeholdsmodus". For å håndtere slike tilstander på en strukturert måte, kan vi bruke sealed classes i Kotlin, som gjør det enkelt å definere ulike applikasjonsmodi og sikre at kun lovlige operasjoner kan utføres i hver modus.

Et eksempel på en sealed class for applikasjonens tilstand:

kotlin
Copy code
sealed class AppState {
    object Running : AppState()
    object ReadOnly : AppState()
    object Maintenance : AppState()
}

Til slutt, for å gjøre applikasjonen mer dynamisk og konfigurerbar, kan vi bruke funksjoner som feature flags. Dette kan være nyttig for å aktivere eller deaktivere funksjoner på kjøretid, som for eksempel automatisk lagring eller påminnelser. Feature flags gir oss fleksibilitet til å styre applikasjonens oppførsel uten å måtte gjøre endringer i koden.

Et eksempel på en feature flag kan være:

kotlin
Copy code
var remindersEnabled: Boolean = true

Denne variabelen kan kontrolleres for å se om påminnelser skal være aktive, og vi kan sjekke dens verdi før vi utfører oppgaver som involverer påminnelser.

Når vi benytter oss av teknikker som disse—immutable og mutable tilstander, sealed classes for applikasjonens modus, og feature flags for fleksibilitet—kan vi skape applikasjoner som er både stabile og responsive, og som kan tilpasses ulike brukerbehov og situasjoner.

Hvordan designe en RESTful API med Ktor

Når man utvikler en API, er det viktig å følge prinsippene for REST (Representational State Transfer) for å sikre en forutsigbar og effektiv kommunikasjon mellom klienter og servere. RESTful API-er er et kraftig verktøy som muliggjør enkel skalering, håndtering av store datamengder, og sikrer at utviklere kan jobbe med API-er på en intuitiv og forståelig måte.

En viktig del av designet er å sørge for at hver ressurs i systemet har et tydelig identifiserbart URI (Uniform Resource Identifier), og at operasjoner utføres ved hjelp av de riktige HTTP-metodene (GET, POST, PUT, PATCH, DELETE). På denne måten kan API-en skalere lettere, og mellomledd som lastbalanserere kan distribuere forespørsler uten å kreve spesifikke sesjoner for hver klient. Når klienter navigerer API-en, bør det føles ut som å navigere på en nettside med klikkbare lenker.

En RESTful API gir en enhetlig grensesnitt ved å bruke HTTP-metoder for de grunnleggende CRUD-operasjonene. Når en klient utfører en GET-forespørsel til /tasks, mottar de en samling av alle oppgaver i JSON-format. Hvis de ønsker å opprette en ny oppgave, sendes en POST-forespørsel med en JSON-payload til /tasks, og serveren tildeler en ny ID og returnerer den opprettede ressursen med statusen 201 Created og en Location-header som peker på /tasks/{id}. Oppdatering av en eksisterende oppgave gjøres ved å bruke PUT eller PATCH på /tasks/{id}:

• PUT erstatter hele ressursen, så klienten må sende en fullstendig representasjon av oppgaven.

• PATCH på den annen side, brukes for å gjøre delvise oppdateringer, for eksempel å merke oppgaven som fullført.

I tillegg er det viktig å utvikle en konsekvent og logisk URI-struktur. Ved å bruke versjonering som /api/v1, kan man utvikle API-en uten å bryte eksisterende klienter. Når nye funksjoner eller endringer legges til, kan API-en versjoneres til /api/v2, mens /api/v1 fortsatt støtter gamle klienter. For å grupere relaterte ressurser under en overordnet URI, kan man for eksempel bruke /tasks/{id}/tags for å håndtere tags knyttet til en oppgave.

Representasjoner og innhold for API-responsen bør håndteres på en måte som gir klientene det de forventer, og forenkler integrasjonen. REST skiller mellom ressursens identitet (URI-en) og dens representasjon (JSON, XML, etc.). JSON bør være det primære mediatypen, og serveren kan håndtere forespørsler ved å sjekke Accept-headeren for å sende riktig respons. Hypermedialen (HATEOAS) kan også benyttes for å gi klienten mulighet til å oppdage tilgjengelige handlinger dynamisk. Et eksempel på dette kan være at en oppgave inneholder lenker til dens egen informasjon og en lenke for å oppdatere status.

Standardisering av statuskoder og feilsvar er essensielt for en pålitelig klient-server-interaksjon. Når en forespørsel er vellykket, returneres typiske koder som 200 OK, 201 Created eller 204 No Content. I tilfelle av feil skal API-en gi passende svar med koder som 400 Bad Request for ugyldige data, 404 Not Found hvis ressursen ikke finnes, eller 409 Conflict hvis det er en duplikatforespørsel. Feilmeldinger bør alltid inneholde en JSON-struktur med feltene for feil og melding, slik at klienten kan håndtere disse responsene programmatisk.

Filtrering, paginering og sortering er også viktige mekanismer for å håndtere store datamengder. Ved å støtte spørringsparametere som ?completed=false&priority=true for filtrering, ?page=2&pageSize=20 for paginering, og ?sort=createdTimestamp,desc for sortering, kan serveren returnere bare de dataene som er relevante for klienten. Metadata for paginering, som viser antall resultater og nåværende side, bør inkluderes i svaret for å hjelpe klienten med å administrere store datamengder.

Når det gjelder implementeringen, kan man bruke rammeverk som Ktor for å bygge API-en på Linux. Ktor’s ruter gjør det mulig å definere endepunktene i koden på en måte som gjenspeiler URI-strukturen, og ruteparametre som {id} kan benyttes for å hente spesifikke oppgaver. For å håndtere forskjellige typer forespørsler som GET, POST, PUT eller PATCH, benyttes de respektive HTTP-metodene for å definere hvordan serveren skal håndtere dataene som sendes.

Det er også viktig å håndtere innkommende data på en sikker og pålitelig måte. For eksempel, når en klient sender en POST-forespørsel for å opprette en ny oppgave, må serveren dekode JSON-kroppen og validere den før videre behandling. Hvis beskrivelsen er tom, vil serveren returnere en BadRequest-feil. Ved PUT og PATCH kan man sikre at bare de feltene som er nødvendige blir oppdatert.

I tillegg er det viktig å være klar over at API-design ikke bare handler om å få teknikken til å fungere. Godt API-design innebærer at det er lett for utviklere å bruke API-en på en måte som er forutsigbar, lettfattelig, og gir dem tilstrekkelig informasjon til å kunne håndtere eventuelle feil på en effektiv måte.

Hvordan bygge en robust RESTful API med Ktor, Exposed og H2

Ktor er et moderne web-rammeverk som tillater utvikling av raske, asynkrone webapplikasjoner i Kotlin. Sammen med Exposed, et Kotlin-bibliotek som gir en type-sikker DSL for SQL-operasjoner, og H2, en innebygd database som er lett å konfigurere og bruke, gir dette en kraftig plattform for å bygge REST API-er. Ved å integrere disse teknologiene kan vi bygge et API som gir en pålitelig og robust løsning for å håndtere oppgaver, lagre dem i en database og gjøre det enkelt å utføre CRUD-operasjoner.

I et typisk API-oppdrag for oppgaver, slik som vi har her, starter vi med å definere rutene som skal håndtere de forskjellige HTTP-metodene som GET, POST, PUT, PATCH og DELETE. Ved å bryte ned ruter etter funksjonelle moduler blir koden lettere å vedlikeholde og navigere. I stedet for å ha alt i én stor rute, deler vi API-ene opp etter ressurser, som for eksempel en rute for "tasks", og muliggjør dermed enkel team-eierskap og vedlikehold.

Når vi snakker om å bygge et API, er det viktig å sikre at vi har en konsekvent feilhåndtering og svarmodell. Her er det brukt en delt svarmodell som gir en ensartet tilnærming til hvordan feilmeldinger håndteres. Feil blir sendt tilbake med HTTP-statuskoder og et feilsvar som inneholder detaljer om hva som gikk galt. Dette gjør det lettere for klientene å håndtere svarene, ettersom de vet at alle feil blir returnert med en bestemt struktur som kan brukes til feilsøking.

Videre, når man arbeider med databaseoperasjoner, er det viktig å bruke et lagringssystem som er pålitelig og ikke kan forstyrres under operasjoner. H2-databasen, som er innebygd og lagrer data i en fil, gir en lett løsning for utvikling og testing. For mer robuste produksjonsmiljøer kan PostgreSQL være et alternativ, men H2 gir oss fleksibiliteten til å jobbe raskt uten mye ekstra konfigurasjon. For å gjøre databaseoperasjoner enklere og mer Kotlin-spesifikke, benytter vi Exposed-biblioteket. Dette lar oss utføre CRUD-operasjoner på en type-sikker måte og lar oss også definere skjemaer på en enkel og lettfattelig måte.

Når vi bygger selve databasen, begynner vi med å definere tabellen for oppgavene ved hjelp av Exposed’s DSL. Vi definerer de nødvendige feltene for hver oppgave, som beskrivelse, prioritet, fullført-status og tidsstempel for opprettelse. Denne tabellen fungerer som en modell for hvordan oppgavene blir lagret i databasen. Deretter mapper vi hver rad i tabellen til et Kotlin-objekt via TaskEntity, som er vår representasjon av en oppgave.

For å koble API-et vårt til databasen, oppretter vi en tilkobling i Application.module()-funksjonen, der vi spesifiserer URL-en for H2-databasen og oppretter nødvendige tabeller. Når applikasjonen starter, blir nødvendige tabeller automatisk opprettet, og vi kan begynne å gjøre CRUD-operasjoner på oppgavene i systemet.

En viktig del av utviklingen er service-laget, hvor vi pakker logikken for å hente, legge til, oppdatere og slette oppgaver inn i et eget repository. Dette gjør det enklere å isolere logikken for databaseoperasjoner og gjør koden mer modulær og testbar. Ved å bruke Exposed-transaksjoner kan vi sikre at alle databaseoperasjoner utføres på en pålitelig måte, med automatisk håndtering av transaksjoner, inkludert commit og rollback.

Når vi har opprettet repository-et, kobler vi det til våre Ktor-ruter. Dette gjøres ved å injisere repository-et i våre HTTP-ruter og bruke de nødvendige metodene for å håndtere innkommende HTTP-forespørsler. For eksempel kan vi bruke GET-metoden for å hente alle oppgavene, POST for å legge til en ny oppgave, PUT for å oppdatere en eksisterende oppgave, og DELETE for å fjerne en oppgave fra systemet. Ved å håndtere alle disse operasjonene på en konsistent måte sikrer vi at systemet vårt er pålitelig og lett å vedlikeholde.

Et API som dette gir flere fordeler. For det første, ved å bruke Ktor og Exposed, får vi et system som er lettvektig, raskt, og utviklingsvennlig. H2 gir oss en enkel løsning for lagring, og ved å bruke transaksjoner kan vi sikre at dataene våre alltid er konsistente. For det andre, ved å følge REST-prinsippene og sørge for at API-et vårt er strukturert på en forståelig måte, blir det lettere for både utviklere og sluttbrukere å bruke og utvide applikasjonen.