Backend-roadmap

Hva: Programmer som lytter etter og svarer på forespørsler.

Hvorfor: Grunnenheten alt backend-arbeid bygger rundt.

Bør kunne: Forstå livssyklusen til en forespørsel fra mottak til svar.

Hva: GET, POST, PUT, PATCH, DELETE og deres semantikk.

Hvorfor: Riktig bruk gjør API-er forutsigbare for alle som konsumerer dem.

Bør kunne: Velge riktig metode og statuskode for hver operasjon.

Hva: Arkitekturstil for ressursorienterte API-er.

Hvorfor: Fortsatt den dominerende stilen for offentlige og interne API-er.

Bør kunne: Designe endepunkter rundt ressurser, ikke handlinger.

Hva: Tekstbasert dataformat for utveksling mellom klient og server.

Hvorfor: Standardformatet for nesten alle moderne API-er.

Bør kunne: Designe konsistente JSON-strukturer for responser.

Hva: Beslutninger om navngiving, versjonering og struktur.

Hvorfor: Dårlig API-design koster tid for alle som bruker det senere, inkludert deg selv.

Bør kunne: Skrive API-er som er forutsigbare uten dokumentasjon i hånden.

Hva: Kobling mellom URL og handler-funksjon.

Hvorfor: Organiserer hvordan forespørsler når riktig logikk.

Bør kunne: Strukturere routes i moduler etter ressurs.

Hva: Funksjoner som kjører før eller etter en handler, f.eks. logging og auth.

Hvorfor: Lar deg gjenbruke tverrgående logikk uten duplisering.

Bør kunne: Skrive egen middleware for autentisering og feilhåndtering.

Hva: Kontroll av at inndata har riktig form og innhold.

Hvorfor: Ugyldig data som slipper gjennom skaper feil lenger inn i systemet.

Bør kunne: Validere all inndata på serveren, uansett hva klienten gjør.

Hva: Bekrefte identiteten til den som gjør forespørselen.

Hvorfor: Forutsetning for alt som skal være beskyttet.

Bør kunne: Implementere innlogging med sikker passordhåndtering.

Hva: Bestemme hva en autentisert bruker har tilgang til.

Hvorfor: Skiller "hvem er du" fra "hva får du lov til".

Bør kunne: Bygge rollebasert eller ressursbasert tilgangskontroll.

Hva: Serverbasert tilstand knyttet til en innlogget bruker.

Hvorfor: En av to hovedmåter å holde brukere innlogget på.

Bør kunne: Vite når sessions passer bedre enn tokens.

Hva: Signerte tokens som bærer brukerinformasjon uten serverlagring.

Hvorfor: Vanlig i APIer som skal være stateless eller brukes på tvers av tjenester.

Bør kunne: Forstå signering, utløp og hvor tokens bør lagres trygt.

Hva: Liten data lagret i nettleseren og sendt automatisk med forespørsler.

Hvorfor: Brukes til sessions, preferanser og autentisering.

Bør kunne: Sette sikre, httpOnly-cookies riktig.

Hva: Strukturert registrering av hendelser i systemet.

Hvorfor: Eneste realistiske måte å forstå hva som skjedde i produksjon.

Bør kunne: Logge med riktig alvorlighetsgrad og uten sensitive data.

Hva: Konsistente feilresponser og robust håndtering av unntak.

Hvorfor: En krasjet server er verre enn en tydelig feilmelding.

Bør kunne: Returnere strukturerte feil med riktig statuskode.

Hva: Automatiserte tester av endepunkter og logikk.

Hvorfor: Gir trygghet til å endre backend-kode uten frykt for regresjoner.

Bør kunne: Skrive integrasjonstester for de viktigste endepunktene.

Hva: Beskyttelse mot vanlige angrep som SQL-injeksjon og XSS.

Hvorfor: Backend håndterer ekte data og forretningslogikk.

Bør kunne: Kjenne OWASP Top 10 og hvordan de gjelder egne systemer.

Hva: Asynkront arbeid som kjører utenfor forespørsel-svar-syklusen.

Hvorfor: Noen oppgaver tar for lang tid til å holde en bruker ventende.

Bør kunne: Skille mellom det som må skje synkront og det som kan køes.

Hva: HTTP-kall utløst av hendelser i et annet system.

Hvorfor: Standard måte for systemer å varsle hverandre uten polling.

Bør kunne: Bygge og sikre egne webhook-mottakere.

Hva: Håndtering av binærdata sendt fra klienten.

Hvorfor: Mange applikasjoner trenger å ta imot bilder, dokumenter eller kvitteringer.

Bør kunne: Validere filtype og størrelse før lagring.

Hva: Beskrivelse av endepunkter, f.eks. via OpenAPI/Swagger.

Hvorfor: Gjør API-et brukbart for andre uten å måtte lese kildekoden.

Bør kunne: Holde dokumentasjonen synkronisert med faktisk oppførsel.