Det låter banalt. Men det är ett rätt fundamentalt skifte från hur webbskrapning fungerat de senaste tio åren.

Vad ett traditionellt scraper-API faktiskt gör

De flesta etablerade tjänsterna löser ett enda problem: att hämta sidan. De roterar proxyer, kör headless-browsers, hanterar Cloudflare och returnerar HTML till dig.

Sen är det ditt jobb.

Du sitter där med en sträng på 300 KB och ska skriva selektorer i BeautifulSoup, Cheerio eller Playwright. När sajten ändrar sin layout, vilket händer ofta, går din parser sönder utan att du märker det förrän datan blir tom eller fel. Du bygger alltså en lagerkaka: API:et hämtar, din kod tolkar, din databas lagrar. Tre ställen där saker kan gå sönder.

Om du är ny på vad ett API egentligen är rekommenderar jag att börja med grunderna kring API:er innan du dyker djupare.

Skiftet från schema till JSON-utdata

Den nya modellen byter ut HTML-svaret mot strukturerad data direkt. Du skickar något i stil med:

”`json

{

”url”: ”https://exempel.se/produkt/123”,

”schema”: {

”namn”: { ”type”: ”string”, ”example”: ”Sneakers” },

”pris”: { ”type”: ”number”, ”example”: 899 },

”lager”: { ”type”: ”boolean”, ”example”: true }

}

}

”`

Tillbaka får du ett rent JSON-objekt med exakt de fälten, redan typade. Ingen parsning. Ingen efterbehandling. Ingen kod som ska underhållas när sajten byter klassnamn på sina prisetiketter.

Under huven används en språkmodell som läser den renderade sidan och plockar ut värdena som matchar schemat. Det är detta som gör att samma anrop fungerar mot en webbshop, en nyhetsartikel eller en jobbannons utan att du behöver skriva ny logik.

Skillnaden märks direkt när du börjar bygga något i produktion. En integration som tidigare krävde två dagars selektorarbete blir en eftermiddag.

Varför effektiviteten ofta blir bättre

Påståenden om ”6-7 gånger effektivare” än konkurrenterna är värda att granska kritiskt, det beror helt på vad man mäter. Men det finns några reella faktorer som drar ner kostnaden:

• Färre misslyckade anrop. När extraktionen sker server-side och valideras mot schemat slipper du anrop som returnerar tom data
• Mindre dataöverföring. JSON med fem fält är hundratals gånger mindre än en full HTML-sida
• Inga separata ”credits” för olika features. Traditionella tjänster tar ofta 5-75 credits för ett JS-renderat anrop och 1 credit för ett enkelt, det gör prissättningen oförutsägbar
• Mindre kod att underhålla. Den dolda kostnaden i scraping är inte API-avgiften, det är utvecklartid

Den sista punkten är den största. Du sparar inte 50 öre per anrop. Du sparar fyra timmar i veckan på att laga sönderbruten parsing.

Vad du faktiskt kan bygga med det

Användningsfallen är desamma som tidigare, bara enklare att komma igång med:

Prisbevakning mot konkurrenters webbshoppar. Sammanställning av jobbannonser från flera plattformar. Insamling av öppna data från svenska myndighetssidor där det inte finns något publikt API. Aggregering av nyheter eller fastighetsannonser till en egen tjänst.

Just det sista är intressant. Många svenska sajter saknar fortfarande öppna API:er trots att informationen är publik. Hemnet, Blocket och flera kommunsidor är klassiska exempel där utvecklare i åratal har byggt egna lösningar.

Det juridiska kring webbskrapning

Här blir det viktigt att vara nykter. Att skrapa en webbsida är inte automatiskt lagligt bara för att tekniken är smidig.

Datainspektionen (numera Integritetsskyddsmyndigheten) har varit tydlig med att personuppgifter omfattas av GDPR även när de hämtas från publika sidor. Skrapar du namn, e-post eller andra identifierande data utan rättslig grund, då har du ett problem oavsett hur snyggt JSON-svaret ser ut.

Tre saker att kolla innan du skrapar något:

1. Sajtens villkor. Många förbjuder explicit automatiserad åtkomst
2. robots.txt. Inte juridiskt bindande, men ett tydligt signalvärde
3. Vilken typ av data. Aggregerad statistik är något helt annat än personuppgifter

För rena tekniska data, produktpriser, väderdata, börskurser, är riskerna oftast små. För allt som rör individer: var försiktig.

När du inte ska använda ett scraper-API

Det finns en frestelse att lösa allt med ett snyggt nytt verktyg. Gör inte det.

Om sajten du vill hämta data från har ett öppet API, använd det. Det är snabbare, billigare och stabilare. SCB, Trafikverket, Naturvårdsverket och en lång rad andra svenska aktörer publicerar data via vanliga REST-endpoints. Att skrapa deras webbsidor i stället är att göra livet onödigt krångligt för sig själv.

Är det en engångskörning på en handfull sidor? Skriv ett litet Python-script med requests och BeautifulSoup. Du behöver ingen tjänst.

Är volymen riktigt hög och datan komplex? Då börjar LLM-baserad extraktion kosta, varje anrop drar tokens hos modellen som körs i bakgrunden. För skrapning i miljonklassen kan en handskriven parser fortfarande vara billigare per anrop.

Vad du bör titta efter när du jämför tjänster

Om du står inför valet mellan flera leverantörer:

Prissättningsmodellen är viktigare än listpriset. En tjänst som kostar 0,01 dollar per anrop men tar 50 credits för ett JS-renderat anrop kan i praktiken bli dyrare än en som tar 0,03 dollar flat rate. Räkna på dina faktiska anrop, inte på marknadsföringspriset.

Schemavalidering. Returneras tomma fält eller felaktiga datatyper utan varning? Det är värre än ett rent fel, du upptäcker problemet först när din databas är full av skräp.

JS-rendering ingår eller inte. Många moderna sajter laddar innehåll med JavaScript efter att HTML:en levererats. Utan rendering får du en tom sida.

Stealth-funktioner. Hur tjänsten hanterar Cloudflare, anti-bot-system och CAPTCHA avgör om den faktiskt fungerar mot de sajter du bryr dig om.

Det här är en del av en större trend

LLM-driven dataextraktion dyker upp på fler ställen än bara skrapning. Du ser samma mönster i verktyg som omvandlar dokument till strukturerad data, i kundtjänst-bottar som plockar ut intent från fritext, och i hur AI förändrar kodningsarbetet generellt.

Det gemensamma: att låta en modell tolka ostrukturerad input mot en känd struktur är otroligt mycket billigare nu än för två år sedan. Det öppnar för verktyg som inte var ekonomiskt rimliga tidigare.

Web scraping är bara ett av många områden som påverkas. Men det är ett där förändringen är konkret nog att du kan testa själv på en eftermiddag, och se direkt om det förändrar hur du bygger.

Inlägget Web scraping med strukturerad JSON och hur nya API-typen fungerar dök först upp på MONC.

För dig som följer utvecklingen kring AI-assistenter för programmering är det här intressant av en enkel anledning. Tokens kostar pengar. Och kontextfönstret tar slut.

Vad Semble egentligen gör

Semble är ett open source-verktyg byggt för att ge kodningsagenter ett bättre sätt att hitta relevant kod. I stället för att skanna filsystemet rad för rad med `grep` och sen mata in stora mängder text i språkmodellen, bygger Semble ett semantiskt index över kodbasen och returnerar bara de bitar som faktiskt är relevanta.

Tekniken kombinerar tre saker:

• Statiska embeddings från en liten modell (potion-code-16M) som körs direkt på CPU
• BM25, en klassisk algoritm för textsökning som väger ord efter hur ovanliga de är
• Reciprocal Rank Fusion som slår ihop resultaten från båda metoderna, med extra omrankning baserad på kod-specifika signaler

Det låter krångligt, men poängen är enkel. Vanliga embedding-modeller behöver ett grafikkort och tar tid att köra. Semble klarar sig utan både GPU och API-nycklar.

Varför token-kostnaden är ett verkligt problem

Den som använt Claude Code, Cursor eller liknande agenter på ett större projekt har märkt det. Agenten letar. Den läser. Den letar igen. Snabbt har den dragit 50 000 tokens bara för att hitta en funktion som ligger tre mappar bort.

På månadsbasis blir det dyrt. På företagsnivå blir det väldigt dyrt.

Vill du läsa mer om hur AI-assistenterna fungerar i praktiken har vi skrivit om GitHub Copilot och hur AI gör kodning billigare. Semble pekar mot en specifik del av den ekvationen: själva sökningen i kodbasen, som idag är onödigt slösaktig.

Siffrorna från benchmarken

Utvecklarna bakom Semble har testat verktyget mot ett eget benchmark med cirka 1 250 fråge/dokument-par över 63 repon och 19 språk. Resultaten:

Jämförelsen görs mot CodeRankEmbed, en betydligt större kodtränad modell på 137 miljoner parametrar. Att en modell på 16 miljoner parametrar når 99% av den prestandan, samtidigt som den körs hundratals gånger snabbare, är ovanligt.

Att ta siffrorna med en nypa salt är klokt. Det är utvecklarnas eget benchmark. Men idén är solid och resultatet stämmer med vad andra statiska embedding-modeller visat: för retrieval-uppgifter behöver du inte den största modellen.

Vad betyder ”statiska embeddings”?

En vanlig embedding-modell läser hela texten varje gång och beräknar en vektor utifrån sammanhanget. Det är dyrt. En statisk embedding-modell tränas så att varje ord eller token får en förbestämd vektor som inte ändras vid körning. Då räcker det med en uppslagning plus lite efterbearbetning.

Skillnaden i hastighet märks direkt. Skillnaden i kvalitet är mindre än man tror, åtminstone för kodsökning där exakta ord och symbolnamn väger tungt.

Installation och hur du kommer igång

Semble finns på pypi.org och installeras enklast med pip eller uv. För svenska utvecklare som redan har en Python-miljö igång handlar det om en enda kommandorad.

Verktyget indexerar din kodbas lokalt. Inga API-nycklar. Ingen data som skickas till en extern tjänst. Det är värt att lyfta fram i en tid när många AI-verktyg kräver att du laddar upp din kod till någon annans server.

För utvecklare som vill följa projektets utveckling och teststatus finns kodbasen kontinuerligt testad via app.codecov.io.

Vem har nytta av det här?

Semble är inte tänkt att ersätta din IDE:s sökruta. Det är byggt för agenter. Men det öppnar för några konkreta användningsfall:

Om du bygger egna AI-agenter som ska navigera kodbaser blir Semble en naturlig komponent. Det är öppen källkod, körs lokalt och är snabbt nog för att integreras i en interaktiv loop.

Om du använder Claude Code eller liknande verktyg professionellt och märker att tokenkostnaden skenar, kan ett MCP-baserat verktyg framför Semble vara en utväg.

Om du är nyfiken på hur retrieval för kod fungerar är det ett pedagogiskt projekt. Koden är begränsad nog att läsa igenom på en eftermiddag, och kombinationen BM25 + embeddings + RRF är ett standardmönster som dyker upp överallt i moderna sökmotorer.

Att skriva sina egna agenter har blivit förvånansvärt enkelt det senaste året. Vi gick igenom det i artikeln om en kodningsagent på 400 rader shell, Semble är pusselbiten som hanterar ”hur hittar agenten rätt fil att titta i”.

Den större trenden handlar om små modeller och smart användning

Det är lätt att tänka att AI-utveckling bara handlar om större modeller. Mer parametrar, fler GPU:er, högre kostnad. Semble pekar åt andra hållet. En 16-miljoners-parametrar-modell som körs på en vanlig laptop och slår betydligt större modeller på den specifika uppgift den är byggd för.

Det är samma utveckling vi sett på andra håll inom AI. Specialiserade små modeller som löser ett avgränsat problem bättre än de stora generalisterna. För svenska utvecklare som vill experimentera utan att bränna molnbudget är det goda nyheter.

Om generativ AI som koncept är nytt för dig har vi en bredare genomgång i Generativ AI: vad det är och varför så många pratar om det. Där hittar du grunderna som gör att resten av AI-världen blir lättare att navigera.

Det jag tar med mig från Semble är inte själva verktyget, utan principen. Token-effektivitet kommer bli en av de viktigaste mätstickorna för AI-verktyg de närmaste åren. Inte för att tokens är dyra i sig, utan för att kontextfönstret är en ändlig resurs. Den som slösar fyller det med skräp. Den som är effektiv lämnar plats åt det som faktiskt löser problemet.

Inlägget Semble möjliggör effektiv kodsökning för AI-agenter med 98% färre tokens än grep dök först upp på MONC.

Att en match mellan två fotbollslag ska sättas till oddset 1.85 mot 4.20 låter enkelt. Men bakom siffrorna finns idag en hel teknikstack med maskininlärning, realtidsdataflöden och statistiska modeller som tillsammans behandlar tiotusentals datapunkter per sekund. På bara några år har oddssättning gått från att vara hantverk där erfarna analytiker satte priser efter magkänsla, till en data driven process där neurala nätverk korrigerar oddsen flera gånger per minut under en match.

Här går vi igenom hur tekniken faktiskt fungerar, vilka datakällor som används och varför live odds har blivit ett av de mest beräkningsintensiva problemen inom konsumentteknik.

Från manuell oddssättning till datadrivna modeller

Traditionellt baserades odds på säsongssnitt, formkurvor och en analytikers bedömning. Den modellen har inte försvunnit, men den har försetts med ett tjockt lager av automation. Moderna oddsmotorer drar in matchstatistik, spelarbiometri, väderdata, skaderapporter, vilodagar mellan matcher, resvägar och till och med röststämningen i sociala medier inför en match.

Enligt branschanalyser från WSC Sports klarar moderna maskininlärningsmodeller idag att förutsäga matchvinnaren i stora ligor med 75 till 85 procents träffsäkerhet, jämfört med 50 till 60 procent för traditionella statistiska metoder. Ett amerikanskt patent från oddsleverantören som ligger bakom flera av de stora sportböckerna beskriver hur två eller flera oddsformler körs parallellt och korreleras mot historiska utfall i en så kallad cross-databas innan ett slutgiltigt odds skickas vidare till användaren.

Det är viktigt att skilja på två saker som ofta blandas ihop. Det ena är spelbolagets prismodell, som är tekniken vi beskriver här. Det andra är spelarens egen modell, alltså AI-verktyg som tipstjänster använder för att försöka hitta värdespel. De delar metoder men har motsatta mål: spelbolaget vill att oddset ska vara så nära den verkliga sannolikheten som möjligt med ett påslag, spelaren letar efter situationer där oddset avviker från den verkliga sannolikheten.

Vilka datakällor matas in i modellerna?

Mängden data som strömmar in i en modern oddsmotor är betydligt större än vad många tror. För en enskild fotbollsmatch i högsta serien handlar det inte sällan om över 50 distinkta variabler. En grov uppdelning ser ut så här:

• Strukturell data som ligaplacering, head-to-head-historik, hemma- och bortastatistik, antal vilodagar och resväg sedan föregående match.
• Spelardata som individuell formkurva, skadestatus, antal speltimmar de senaste veckorna, biometri från träningsdata och positionsdata från GPS-västar.
• Realtidsdata under match som boll- och spelarpositioner, hörnor, gula kort, tempo, expected goals och passningsstatistik.
• Externa faktorer som väder, vindstyrka, banunderlag, publikstorlek och tidszonsskillnader för bortalaget.
• Marknadsdata som linjerörelser hos andra spelbolag, volymer på olika utfall och stora insatser som triggar omräkning.

Datakällorna jämförda

Olika datatyper bidrar med olika mycket till modellens prediktiva styrka. Tabellen nedan visar en förenklad bild av hur tunga olika kategorier brukar väga i typiska modeller för fotboll och hockey.

Vilka modeller används för att räkna ut själva oddset

Det finns ingen enskild modell som dominerar branschen, utan oddsmotorer kombinerar i regel flera olika tekniker. De vanligaste familjerna är:

• Logistisk regression och Poisson-modeller är det klassiska statistiska skiktet och används fortfarande för många bas-uträkningar, särskilt i fotboll där Poisson-fördelningen passar bra för antal mål.
• Gradient boosting-modeller som XGBoost och LightGBM är arbetshästar i branschen för att vikta in dussintals variabler och hitta icke-linjära samband.
• Neurala nätverk och djupinlärning används främst för komplexa, sekventiella mönster som hur en match utvecklas över tid eller för att modellera enskilda spelares påverkan.
• Monte Carlo-simulationer körs för att simulera tusentals till miljontals tänkbara matchutfall och därigenom uppskatta sannolikheter för specifika händelser, exempelvis att en match slutar 2-1 eller att en viss spelare gör mål.
• Förstärkningsinlärning börjar dyka upp i live-oddsmotorer där modellen kontinuerligt belönas eller bestraffas baserat på hur bra prognoserna stämmer mot verkliga utfall.

Hur sannolikhet översätts till odds

När modellen har räknat ut sannolikheten för ett visst utfall är steget till ett offentliggjort odds inte mer komplicerat än lite gymnasiematematik. Ett decimalodds är teoretiskt 1 dividerat med sannolikheten.

Om en modell uppskattar att hemmalaget vinner med 55 procents sannolikhet blir det ”rättvisa” oddset 1.82. Spelbolaget lägger sedan på en marginal, ofta kallad overround eller juice, vilket innebär att summan av implicerade sannolikheter på alla utfall överstiger 100 procent. Det är just denna marginal som är spelbolagets statistiska fördel över tid.

Ett räkneexempel för en fotbollsmatch med tre möjliga utfall ser ut så här:

Live odds är där maskinerna verkligen briljerar

Det är i live-betting som AI-aspekten blir mest synlig för spelaren. När en match pågår behöver oddsen räknas om bokstavligen flera gånger per minut. En hörna, ett byte, en skadad spelare eller bara att tempot går ner kan ändra sannolikheterna för slutresultatet på ett ögonblick. För att hantera detta krävs en realtidsinfrastruktur med extremt låg latens. Det handlar i praktiken om tre saker som måste fungera parallellt:

• Datainsamling i realtid: positionsdata, händelsedata och statistik strömmas in från arenan via leverantörer som Sportradar och Genius Sports, ofta via dedikerade observatörer på plats kombinerat med kamerabaserad spårning.
• Modellinferens på millisekundnivå: tränade modeller måste kunna producera ett nytt sannolikhetsestimat för varje marknad inom någon eller några tiotals millisekunder efter att ny data anlänt.
• Riskhantering: varje insats som läggs påverkar exponeringen mot ett utfall, vilket kan motivera att flytta oddsen även om den underliggande sannolikheten inte ändrats.

För många erfarna spelare är det här som det blir intressant att titta på olika spelbolags utbud. Sajter med stort matchutbud och bred täckning, exempelvis Bethard casino och liknande svensklicensierade plattformar, behöver underhålla tusentals samtidiga marknader på allt från Allsvenskan till MMA, vilket bara är möjligt med tung automatisering.

Begrepp som spelaren själv möter i tekniken

Det är inte bara spelbolagen som använder matematiska begrepp. Som spelare stöter du på samma underliggande koncept om du läser någon bettingguide. De viktigaste:

• Implicerad sannolikhet är det som oddset säger om hur troligt utfallet är. För decimalodds 2.50 motsvarar det 40 procent.
• Expected value (EV) är det förväntade ekonomiska utfallet av ett spel räknat över oändligt många upprepningar. Positivt EV betyder att oddset är högre än den verkliga sannolikheten.
• Varians är hur mycket utfallen avviker från medelvärdet på kort sikt. Ett spel kan ha positivt EV men hög varians, vilket innebär stora svängningar.
• Closing line value är skillnaden mellan det odds du fick och det odds som gällde när matchen startade. Branschen ser detta som den bästa enskilda indikatorn på långsiktig spelskicklighet.

Var står svensk reglering i förhållande till AI-modellerna?

Svenska spelinspektionen kräver att alla licensierade aktörer kan redovisa hur deras spel fungerar och att rättvisa kan verifieras. För digitala casinospel sker detta genom RNG-certifieringar, men för sportbetting finns inga formella krav på att en oddsmodell ska vara förklarbar. Däremot finns det en växande diskussion, särskilt i USA, om reglering av AI-driven oddssättning där delstaten Illinois utrett krav på transparens i algoritmerna.

På EU-nivå kan AI-förordningen i framtiden komma att klassa vissa typer av personifierad oddssättning som högrisksystem, men i nuläget är området i hög grad oreglerat på modellnivå. För spelaren betyder det att skillnaden mellan olika spelbolags odds inte bara handlar om marginal, utan också om vilken modell som ligger bakom. För information om hur svensk spellicens fungerar i övrigt finns en bra översikt hos Spelinspektionen.

Vad detta betyder för dig som följer sport

Sportbetting är inte längre en bransch där erfaren magkänsla räcker, vare sig hos spelbolagen eller hos seriösa spelare. Den som sätter oddset har idag en datadriven modell som processar mer information på en sekund än en mänsklig analytiker hinner med på en vecka. För den som spelar för nöjes skull spelar detta mindre roll, men det är värt att vara medveten om att marginalerna som spelbolaget arbetar med är just statistiskt designade för att ge huset en fördel över tid.

För den som vill förstå sin sport på djupet är det däremot en spännande utveckling, eftersom mycket av tekniken bakom oddsmodellerna också används av klubbar och förbund för att analysera spelarprestationer, taktiska upplägg och rekrytering.

Inlägget AI och statistik bakom moderna sportodds: så räknar maskinerna ut sannolikheten dök först upp på MONC.

Det här är den verkliga lärdomen från det senaste årets explosion av agentiska kodverktyg som Claude Code, Cursor och GitHub Copilot Workspace: själva skrivandet är inte längre flaskhalsen. Granskningen är det. Specifikationen är det. Arkitekturen är det.

Vad agentisk kodning egentligen är

En agentisk kodningsagent är inte autocomplete. Den får en uppgift, planerar steg, kör kommandon i terminalen, läser filer, skriver kod, kör tester och rättar sig själv när något går fel. Den jobbar i loopar tills uppgiften är klar, eller tills den kör fast.

Skillnaden mot tidigare AI-assistenter är att agenten agerar. Den frågar inte ”vill du att jag skriver den här funktionen?”. Den skriver den, kör den, läser felmeddelandet och försöker igen.

Det förändrar arbetsflödet i grunden. Du sitter inte längre och knattrar. Du beskriver, övervakar och bedömer.

Tio principer som visat sig hålla

Utvecklare som arbetat seriöst med agentiska verktyg det senaste året landar i ungefär samma slutsatser. Här är de som återkommer mest:

1. Skriv specifikationen, inte koden. Den största hävstången ligger i att formulera problemet exakt. En vag prompt ger vag kod. En tydlig spec med inputs, outputs, edge cases och acceptanskriterier ger användbar kod.

2. Behandla agenten som en junior med oändlig energi. Den jobbar snabbt, glömmer kontext, och behöver tydliga ramar. Lämna inte arkitekturbeslut åt den.

3. Testa innan, inte efter. Skriv testerna själv eller låt agenten skriva dem först, sen koden. Annars skriver agenten kod som passar testerna den själv hittar på.

4. Små commits, ofta. När kod är billig är det också billigt att slänga. Commit-historiken är din säkerhetslina när agenten gör något oväntat.

5. Granskning är inte valfritt. Det är arbetet. Att läsa varje rad agenten producerar är inte en flaskhals, det är där värdet skapas.

6. Verktyg framför kontext. Ge agenten tillgång till linters, typkontroller, tester och dokumentation. Den blir bättre av att kunna verifiera, inte av att få mer instruktioner.

7. Kortare loopar. En agent som kör tester på 3 sekunder hittar fel snabbare än en som väntar 90 sekunder. Investera i tooling.

8. Acceptera att kod är slit-och-släng. Prototyper behöver inte vara vackra. De behöver bevisa eller motbevisa en idé.

9. Granska säkerhet manuellt. Agenter är fortfarande dåliga på att tänka som angripare. SQL-injektioner, autentiseringsfel och läckta hemligheter glider igenom.

10. Behåll smaken. Det som skiljer god kod från fungerande kod är fortfarande en mänsklig bedömning. Konsistens, läsbarhet, namngivning. Outsourca inte det.

Det som faktiskt förändras i vardagen

Tänk dig att du ska bygga en enkel API-endpoint som hämtar användardata. För några år sedan skulle du läsa dokumentation, skriva ruttdefinitionen, koppla in databasen, hantera fel och skriva tester. Kanske två timmars jobb.

Idag säger du till agenten: ”Bygg `/api/users/:id` med JSON-respons, 404 vid okänd användare, integrationstest mot testdatabasen.” Den är klar på fyra minuter.

Men då börjar ditt jobb. Returnerar den rätt fält? Läcker den känslig data? Är felhantering konsekvent med resten av kodbasen? Använder den samma autentiseringsmönster som andra endpoints? Det är frågor agenten inte ställer själv, och som blir uppenbara först vid läsning.

För nybörjare betyder det här något viktigt. Om du inte förstår vad en API faktiskt är och hur HTTP-statuskoder fungerar, kan du inte granska. Och kan du inte granska, blir du beroende av att agentens output råkar vara rätt.

Det blir billigare att prova, dyrare att vara slarvig

En sak som ändras är ekonomin för experiment. Att bygga en prototyp kostade tidigare timmar. Nu kostar det minuter. Det betyder att tröskeln för att testa en idé sjunker dramatiskt, vilket är bra.

Samtidigt: kostnaden för att producera dålig kod sjunker också. Och dålig kod som körs i produktion drar med sig samma problem som alltid. Säkerhetshål, prestandaproblem, underhållsskuld. Bara att nu finns det mycket mer av den.

Den som inte kan läsa kod kan inte heller granska den. Och granskning är jobbet nu.

Vad du bör lära dig nu

Om du är ny i utveckling är frestelsen att hoppa direkt till AI-verktygen. Det är förståeligt. Men det leder till en konstig position: du producerar kod du inte förstår, för problem du inte fullt definierat.

Bättre väg: lär dig grunderna ordentligt först. HTML, CSS, JavaScript, en backend-stack, hur en webbläsare faktiskt fungerar, hur localhost används under utveckling. Sen lägger du på AI-lagret. Då blir agenten en accelerator, inte en krycka.

Det är samma princip som med vibe coding, du kan komma långt på känsla och AI-stöd, men du tar dig inte hela vägen utan grundförståelse.

Granskning som färdighet

Det här är den verkliga kompetensförskjutningen: kodgranskning blir den viktigaste tekniska färdigheten.

Vad innebär det praktiskt? Att kunna läsa en diff och se inte bara vad koden gör, utan vad den inte gör. Hittar agenten edge cases? Hanterar den fel konsekvent? Följer den projektets konventioner? Introducerar den dolda beroenden?

Det är arbete som kräver erfarenhet, smak och tålamod. Tre saker AI fortfarande är dålig på.

Verktyg som GitHub Copilot och dess agentiska efterföljare är bra på syntax, mönster och boilerplate. De är sämre på att fråga ”borde vi verkligen bygga det här?”. Den frågan är din.

Arkitektur blir viktigare, inte mindre viktigt

En vanlig missuppfattning är att AI gör arkitektur överflödigt. ”Om kod är billig, bygg bara om när det inte funkar.”

Det stämmer för enskilda funktioner. Det stämmer inte för system. Datamodeller, API-kontrakt, integrationspunkter, sånt som många komponenter beror på, är fortfarande dyrt att ändra. Inte för att skriva om koden, utan för att migrera data och uppdatera klienter.

Agenter är duktiga på att skriva kod inom en given arkitektur. De är dåliga på att välja arkitektur. Det betyder att utvecklare som kan tänka i systemtermer, vilka komponenter, vilka gränssnitt, vilka antaganden, blir mer värdefulla, inte mindre.

Säkerhet är fortfarande mänsklig

En sak som är värd att upprepa: agenter är systematiskt dåliga på säkerhetstänk. De skriver gärna kod som fungerar för ärliga användare och faller sönder vid första angreppet.

Vanliga problem som glider igenom:

• Användarinput som inte saneras innan databasfrågor
• Autentisering som är på men inte korrekt på alla endpoints
• Hemligheter som hamnar i loggar eller felmeddelanden
• Race conditions som bara märks under belastning

Här hjälper det att förstå hur kryptografiska grunder som hash-funktioner och kodning fungerar, och att veta var känslig data faktiskt rör sig genom systemet.

Den nya arbetsdagen

Så hur ser en utvecklardag ut när kod är billig?

Mer tid på problem, mindre på syntax. Mer läsande, mindre skrivande. Fler korta cykler där agenten producerar något, du granskar, justerar instruktionen och kör igen. Mer tid att fundera på om funktionen ens ska finnas.

Det låter mindre av kodning och mer av produktarbete. Och det är precis vad det är.

Den utvecklare som klarar sig bäst i det här landskapet är inte den som skriver mest kod. Det är den som vet vilken kod som är värd att skriva, och har smaken att se när agenten gjorde något smart, och när den gjorde något som ser smart ut men inte är det.

Skillnaden är subtil. Den syns inte i diff:en. Men den syns i koden som lever vidare om två år.

Inlägget Hur AI gör kodning billigare och förändrar utvecklarnas arbetsuppgifter dök först upp på MONC.

Projektet heter Pu.sh och dök upp på Hacker News. Det är intressant av en specifik anledning: det visar hur långt du kan komma när du vägrar lägga till beroenden. Och det säger något om hur AI-kodning faktiskt fungerar i praktiken.

Vad är en kodningsagent egentligen?

En kodningsagent är ett program som låter en språkmodell skriva och köra kod på din dator. Den läser filer, ändrar dem, kör kommandon i terminalen och rapporterar tillbaka. Tänk GitHub Copilot fast med rättigheter att faktiskt göra saker, inte bara föreslå.

Skillnaden mellan en chattbot och en agent ligger i verktygen. Chattboten svarar med text. Agenten anropar funktioner: `read_file`, `write_file`, `bash`, `grep`. Modellen bestämmer själv när och hur. Resultatet skickas tillbaka som en del av samtalet, och loopen fortsätter tills uppgiften är klar.

Det är därför Pu.sh har sju verktyg: bash, read, write, edit, grep, find, ls. Det är minimibesättningen för att en agent ska kunna jobba i ett kodprojekt. Mer än så är trevligt men inte nödvändigt.

Varför 400 rader shell är imponerande

De flesta AI-agenter idag byggs i Python eller TypeScript med tunga ramverk. LangChain. LlamaIndex. AutoGen. De drar in hundratals beroenden och kräver en specifik miljö för att ens starta.

Pu.sh går åt motsatt håll. Regeln var: inga nya beroenden, under 500 rader kod. Bara verktyg som finns på varje Unix-system sedan 80-talet.

Det betyder att utvecklaren tvingades göra obekväma saker. JSON-parsning i `awk` till exempel, ett språk från 1977 som aldrig var tänkt för det. OpenAI:s tool-loop med reasoning-objekt som förs vidare mellan turer, implementerad utan ett enda externt bibliotek.

Det är teknisk envishet snarare än effektivitet. Men poängen är portabiliteten: scriptet kör på en gammal server, en Raspberry Pi, en WSL-installation eller en macOS-laptop. Inget setup-helvete.

AI som skrev koden den körs på

Här blir det filosofiskt intressant. Skaparen är öppen med att hen inte själv skrev det mesta av koden. Claude och Codex skrev awk-delarna. Systemprompten är modifierad från andra projekt. Hen erkänner att hen inte ens kan läsa stora delar av sin egen kodbas.

Det här är vibe coding i renaste form: du beskriver vad du vill ha, AI:n skriver det, du testar att det fungerar. Du går vidare. Förståelsen kommer i andra hand, om alls.

För en del programmerare är det här skrämmande. För andra är det framtiden. Det enda säkra är att det fungerar, Pu.sh kör 90 tester utan API-anrop och har features som auto-komprimering av kontext och checkpoint-funktion.

Vad du kan lära dig av projektet

Tre saker är värda att ta med sig, oavsett om du själv vill bygga något liknande:

Beroenden är skuld. Varje paket du installerar är något som kan gå sönder, behöva uppdateras eller försvinna. Pu.sh visar att du kommer förvånansvärt långt med bara systemets grundverktyg. Det gäller även vanlig webbutveckling, du behöver sällan så många npm-paket som du tror.

API:er är limmet. Hela agenten är i grunden ett program som skickar HTTP-anrop till OpenAI och Anthropic, tolkar svaret, kör verktyg lokalt, och skickar tillbaka resultatet. Om du förstår hur API:er fungerar förstår du också hur 95 % av AI-verktygen är byggda. Det är ingen magi.

Begränsningar tvingar fram kreativitet. Regeln ”max 500 rader, inga nya beroenden” är vad som gjorde projektet intressant. Utan begränsningen hade det blivit ännu en Python-agent bland tusen.

Begränsningar du inte ska ignorera

Pu.sh har medvetna luckor. Ingen TUI, ingen streaming, inget bildstöd, ingen OAuth, fungerar inte på Windows. Skaparen själv listar ”dignity” som något som inte ingår, ett halvt skämt, halvt allvarligt.

Det är ärligt. En 400-rads shell-agent är inte rätt verktyg för ett produktionsteam som behöver granskning, säkerhet och stöd för flera användare. Det är ett verktyg för någon som vill experimentera, lära sig hur agenter fungerar, eller köra något snabbt på en server utan installation.

För svenska utvecklare som vill in i AI-kodning är GitHub Copilot fortfarande den enklaste vägen. Pu.sh är intressant som studieobjekt, inte som dagligt verktyg.

Vad det säger om läget i AI-utveckling

För några år sedan hade ett sådant här projekt krävt ett team. Idag bygger en person det på fritiden, med hjälp av just de modeller agenten anropar. Det är en konstig loop: AI hjälper människor bygga verktyg som låter AI bygga mer.

Tröskeln för att skapa egna AI-verktyg har sjunkit dramatiskt. Du behöver inte längre djup kunskap i maskininlärning. Du behöver förstå API-anrop, kunna läsa dokumentation, och ha tålamod att felsöka när modellen genererar trasig kod.

Det här är varför generativ AI förändrar utveckling så snabbt. Inte för att modellerna är perfekta, det är de inte, utan för att de sänker kostnaden för experiment till nästan noll. En idé som hade tagit en månad tar nu en helg.

Pu.sh kommer förmodligen aldrig bli ett storskaligt projekt. Det behöver inte vara det. Det är ett bevis på koncept: att en kodningsagent inte kräver ett ekosystem av paket. Att shell, curl och awk är tillräckligt mäktiga för att prata med moderna språkmodeller. Och att den största begränsningen i att bygga AI-verktyg år 2026 är fantasin, inte tekniken.

Inlägget En kodningsagent på 400 rader shell och varför det är intressant dök först upp på MONC.

Status quo-bias och banklojalitetens pris

Konsumentverket har i sina granskningar av kreditmarknaden upprepade gånger konstaterat att konsumenter har svårt att tolka och jämföra kreditvillkor, trots att lagstiftningen kräver att kreditgivare redovisar effektiv ränta och total kreditkostnad i sin marknadsföring. Konsumentverkets information om lån och krediter visar att problemet inte är brist på data utan brist på jämförbarhet i det ögonblick konsumenten faktiskt fattar sitt beslut. En bank presenterar sitt erbjudande i en kontext där kunden redan befinner sig i en etablerad relation med banken — det finns ett inarbetat förtroende, en digital inloggning, en historik av tidigare transaktioner som skapar en känsla av tillhörighet. Att i det läget bryta sig loss och söka alternativ kräver en aktiv ansträngning som de flesta väljer bort, inte av ointresse utan av friktion. Det är vad beteendeekonomin kallar status quo-bias, och dess effekt på kreditmarknaden är kvantifierbar: låntagare som jämför erbjudanden från flera kreditgivare betalar i genomsnitt en lägre effektiv ränta än de som stannar hos sin befintliga bank.

Den digitala utvecklingen har dock skapat verktyg som reducerar just den friktionen och gör det möjligt för konsumenter att agera mer rationellt. Jämförelsetjänster för privatlån fungerar som en motkraft till status quo-bias genom att flytta jämförelseprocessen från konsumenten till plattformen. Istället för att besöka fem olika banker och initiera separata kreditprövningar behöver låntagaren fylla i en enda ansökan, och algoritmerna gör det övriga arbetet med att matcha kreditprofilen mot tillgängliga erbjudanden. Det eliminerar inte den psykologiska tröskeln helt — att påbörja en låneansökan kräver fortfarande ett aktivt beslut och en viss ansträngning — men det minskar den dramatiskt. Resultatet syns i den ökade konkurrensen på privatlanemarknaden, där kreditgivare som tidigare kunde räkna med lojala kunder nu tvingas erbjuda villkor som tål jämförelse i en digital miljö där transparensen är omedelbar och obönhörlig.

Ränteskillnader som blir konkreta

Att låna pengar via en jämförelseplattform förändrar inte bara den praktiska processen utan påverkar också det kognitiva ramverket kring själva beslutet. När erbjudanden presenteras sida vid sida blir ränteskillnader konkreta på ett sätt de inte är när man sitter i ett bankkontor och diskuterar med en rådgivare som representerar en enda kreditgivare. En skillnad på två procentenheter i effektiv ränta kan framstå som marginell i ett enskilt samtal men blir omedelbart tydlig och påtaglig i en jämförelsetabell. På ett lån om hundratusen kronor med fem års löptid motsvarar den skillnaden flera tusen kronor i faktisk kostnad, pengar som i praktiken omfördelas från låntagarens hushållsekonomi till bankens marginal utan att låntagaren nödvändigtvis är medveten om det.

Privatlanets ställning i den svenska kreditmarknaden har förändrats markant under det senaste decenniet. Från att ha varit ett relativt standardiserat produkterbjudande med små variationer mellan bankerna har det blivit ett konkurrensutsatt segment där fintech-bolag, nischbanker och traditionella storbanker alla tävlar om samma kundsegment med allt mer differentierade erbjudanden. Den konkurrensen har pressat ned marginalerna och gjort det möjligt för konsumenter med god kreditvärdighet att erhålla villkor som för tio år sedan var förbehållna premiumkunder med omfattande bankengagemang. Samtidigt har den ökade tillgängligheten skapat nya utmaningar — inte minst risken att konsumenter tar på sig mer skuld än de klarar av just för att det blivit friktionsfritt att ansöka.

Aktivt val mot passivitetens kostnad

Balansgången mellan tillgänglighet och ansvarsfullt lånande är kreditmarknadens centrala spänning, och den spänningen blir allt tydligare ju enklare det blir att jämföra och ansöka om krediter. Regleringen sätter ramarna, tillsynsmyndigheterna övervakar efterlevnaden, och jämförelsetjänsterna skapar den transparens som gör att marknadskrafterna faktiskt fungerar till konsumentens fördel. Det som återstår är den enskilda låntagarens förmåga att använda dessa verktyg på ett klokt sätt — att inte bara acceptera det första erbjudandet utan att faktiskt jämföra, att förstå skillnaden mellan nominell och effektiv ränta, och att räkna på den totala kostnaden snarare än att bara titta på månadsbeloppet. Det är ingen komplicerad insikt men det är en insikt som skiljer konsumenter som betalar marknadspris för sina lån från dem som betalar ett påslag för sin egen passivitet.

Inlägget Varför svenska låntagare betalar mer än de behöver dök först upp på MONC.

Sommaren 2025 rapporterade Svensk Handel att stöldrelaterade förluster i detaljhandeln uppgick till 7,2 miljarder kronor, en ökning med nio procent jämfört med året innan. Siffran satte ljus på något som fastighetsägare och näringsidkare redan kände på: att traditionella larm och låsanordningar inte längre räcker som enda skyddslinje. Svaret från säkerhetsbranschen har varit en gradvis övergång mot kombinerade tjänster där fysisk närvaro, digital övervakning och förebyggande riskanalys samverkar i en helhet. Den utvecklingen märks tydligast bland företag som hanterar större fastighetsbestånd, där varje störning innebär direkta ekonomiska konsekvenser och där skyddslösningar måste fungera dygnet runt, oavsett årstid eller personaltillgång. Samtidigt har kraven från försäkringsgivare och myndigheter skärpts, vilket tvingar aktörer i branschen att dokumentera sina insatser med större precision än tidigare. Resultatet är ett landskap där passiva säkerhetssystem snabbt tappar mark till förmån för aktiva, samordnade skyddstjänster.

Polismyndighetens statistik för 2025 visar att anmälda inbrott i verksamhetslokaler minskade med elva procent i kommuner där fastighetsägare anlitade kombinerad rondering och kameraövervakning. Enligt en rapport från Stöldskyddsföreningen spelar den preventiva effekten av synlig bevakningstjänst en avgörande roll, särskilt i områden med hög genomströmning av människor. Rapporten pekar på att bevakningsinsatser som inkluderar regelbunden patrullering minskar risken för upprepade incidenter med upp till fyrtio procent. Det handlar inte enbart om att reagera när något hänt, utan om att skapa en miljö där risken för brott uppfattas som för hög av potentiella förövare. Den insikten har fått allt fler kommuner att ställa krav på aktiva säkerhetsplaner vid upphandling av lokaler för offentlig verksamhet, och liknande krav börjar synas även i privata hyresavtal för kontors- och lagerfastigheter där hyresvärdar konkurrerar om kvalitetsmedvetna företagshyresgäster.

Väktarens förändrade roll

Teknikskiftet har gjort att väktarens roll förändrats i grunden. Moderna bevakningsuppdrag innebär ofta att operatörer övervakar kameraflöden i realtid och koordinerar med fältpersonal som kan vara på plats inom minuter vid larm eller avvikelse. Sensorbaserade system registrerar rörelsemönster, temperaturförändringar och ljud som avviker från det normala, och flaggar automatiskt händelser som kräver mänsklig bedömning. Den typen av hybridlösningar har blivit standard hos säkerhetsföretag som erbjuder bevakning till kommersiella fastigheter, och efterfrågan ökar särskilt från logistikföretag och handelsplatser som opererar utanför kontorstid. Resultatet är en bransch som rör sig bort från timbaserad fakturering mot resultatbaserade avtal där uppdragsgivarens faktiska skyddsnivå står i centrum för avtalsvillkoren snarare än antalet väktartimmar på fakturan.

Ekonomiska incitament och försäkringsrabatter

Kostnadsfrågan driver också förändringen på ett påtagligt sätt. En fastighetsägare som tidigare anlitade stationär bevakning dygnet runt kan med dagens teknik uppnå motsvarande eller bättre skydd till en bråkdel av kostnaden genom att kombinera rondering med fjärrövervakning och automatiserad incidenthantering. Försäkringsbolagen har börjat anpassa sina villkor efter det: flera svenska försäkringsgivare erbjuder sedan 2025 premierabatter på upp till femton procent för fastigheter som kan dokumentera en aktiv bevakningsplan med certifierad leverantör. Det skapar ett ekonomiskt incitament som accelererar övergången från passiva till aktiva säkerhetslösningar. Samtidigt ställer det nya krav på säkerhetsföretagen, som måste kunna visa mätbara resultat snarare än bara fysisk närvaro, och som förväntas leverera transparenta rapporter till uppdragsgivaren efter varje genomfört skift eller hanterad incident.

En faktor som ofta förbises är bevakningens påverkan på hyresgästers trivsel och deras vilja att förnya kontrakt vid periodens slut. Fastighetskonsultföretaget Newsec konstaterade i sin marknadsrapport för fjärde kvartalet 2025 att kontorshyresgäster rankar trygghet som den tredje viktigaste faktorn vid val av lokal, efter läge och hyresnivå. I handelscentrum är effekten ännu tydligare: butiker i anläggningar med synlig och välorganiserad säkerhetstjänst rapporterar genomsnittligt tolv procent högre omsättning per kvadratmeter jämfört med jämförbara lokaler utan dedikerad skyddsinsats. Siffran speglar att kunder stannar längre och handlar mer när de upplever miljön som trygg, och den har fått flera centrumanläggningar att omförhandla sina säkerhetsavtal med tyngdpunkt på synlighet och tillgänglighet snarare än enbart snabb larmrespons vid utlöst larm.

Integration med fastighetsdriften

Framöver kommer säkerhetsbranschen sannolikt att integreras ännu djupare i den dagliga fastighetsdriften. Gränsen mellan fastighetsförvaltning och säkerhetsförvaltning suddas ut när samma digitala plattformar hanterar energiförbrukning, tillträdeskontroll och incidentrapportering i ett gemensamt gränssnitt. Proptech-bolag som kombinerar fastighetsdata med säkerhetsanalys växer snabbt på den nordiska marknaden, och flera har redan slutit partnerskap med etablerade bevakningsföretag för att erbjuda integrerade tjänstepaket som täcker hela kedjan från riskbedömning till operativ insats. För fastighetsägare som vill ligga steget före handlar det inte om att välja mellan teknik och mänsklig kompetens, utan om att hitta rätt kombination där bägge förstärker varandra och skapar en skyddsnivå som varken tekniken eller personalen hade kunnat uppnå på egen hand. De aktörer som lyckas med den balansen kommer att definiera vad professionellt fastighetsskydd innebär under resten av detta decennium, och sannolikt höja ribban för vad både hyresgäster och försäkringsgivare förväntar sig som grundläggande standard.

Inlägget Säkerhetsbranschen formar om synen på fastighetsskydd dök först upp på MONC.

Här går vi igenom hur du skapar CSS-knappar som håller måttet i produktion — från grundstyling och hover-effekter till responsivitet och tillgänglighet.

Grundläggande styling av CSS-knappar

Vi börjar med grunderna. En vanlig <button> utan styling ser rätt trist ut i de flesta webbläsare — grå, platt och med en font-size som varierar beroende på system. Att nollställa det och bygga upp stilen från grunden ger dig full kontroll.

Här är en solid bas att utgå ifrån:

.btn {
  display: inline-flex;
  align-items: center;
  justify-content: center;
  padding: 0.75em 1.5em;
  font-size: 1rem;
  font-family: inherit;
  font-weight: 600;
  line-height: 1;
  color: #fff;
  background-color: #2563eb;
  border: 2px solid transparent;
  border-radius: 6px;
  cursor: pointer;
  text-decoration: none;
  transition: background-color 0.2s ease, transform 0.15s ease;
}

Några saker att notera. font-family: inherit ser till att knappen använder samma typsnitt som resten av sidan, vilket inte är standard i alla webbläsare. padding i em istället för px gör att knappens inre avstånd skalas med textstorleken, något som blir viktigt senare när vi pratar om responsivitet. Och inline-flex i kombination med align-items: center ger dig perfekt centrering av text och eventuella ikoner utan att behöva fuska med line-height.

Det är också värt att sätta border: 2px solid transparent redan från start. Det förhindrar att knappen ”hoppar” i storlek när du senare lägger till en synlig border vid till exempel focus-states.

Hover-effekter som knappar i CSS förtjänar

En knapp utan hover-effekt känns död. Användaren behöver visuell feedback för att förstå att elementet är interaktivt. Men det gäller att inte överdriva — subtila förändringar slår flashiga animationer i nästan alla gränssnitt.

.btn:hover {
  background-color: #1d4ed8;
  transform: translateY(-1px);
}

.btn:active {
  background-color: #1e40af;
  transform: translateY(0);
}

Den lätta förflyttningen uppåt med translateY(-1px) vid hover ger en känsla av att knappen ”lyfts”, och att den studsar tillbaka till normalläget vid active ger en taktil klickkänsla. Det är en klassisk teknik som fungerar bra utan att kännas överdådig.

Vill du skapa en variant med en mer distinkt stil fungerar en ghost-knapp bra som komplement. Den har transparent bakgrund och en synlig ram:

.btn--ghost {
  background-color: transparent;
  color: #2563eb;
  border-color: #2563eb;
}

.btn--ghost:hover {
  background-color: #2563eb;
  color: #fff;
}

Ghost-knappar är praktiska för sekundära actions i ett gränssnitt — de signalerar att det finns ett alternativ utan att konkurrera med primärknappen visuellt. Du kan också experimentera med box-shadow för att ge knappar mer djup vid hover, till exempel box-shadow: 0 4px 12px rgba(37, 99, 235, 0.3). Det ger en subtil glöd-effekt som fungerar bra på mörka bakgrunder utan att ta fokus från innehållet.

Responsiva knappar med CSS

Knappar som ser perfekta ut på en desktop kan bli obrukbara på en mobil. Tummar är inte lika precisa som muspekare, och en knapp som är 32 pixlar hög kan vara direkt frustrerande att träffa på en telefon.

Apples riktlinjer rekommenderar minst 44×44 punkter som tryckyta, och det är en rimlig tumregel. Genom att använda em-baserad padding och clamp() för fontstorleken skapar du knappar som anpassar sig smidigt utan att du behöver skriva mediaqueries för varje breakpoint:

.btn-responsive {
  display: inline-flex;
  align-items: center;
  justify-content: center;
  padding: 0.75em 1.75em;
  font-size: clamp(0.95rem, 0.8rem + 0.5vw, 1.15rem);
  font-family: inherit;
  font-weight: 600;
  line-height: 1;
  color: #fff;
  background-color: #2563eb;
  border: 2px solid transparent;
  border-radius: 6px;
  cursor: pointer;
  transition: background-color 0.2s ease, transform 0.15s ease;
  min-height: 44px;
}

.btn-responsive:hover {
  background-color: #1d4ed8;
  transform: translateY(-1px);
}

.btn-responsive:active {
  transform: translateY(0);
}

clamp(0.95rem, 0.8rem + 0.5vw, 1.15rem) sätter en nedre gräns på 0.95rem och en övre på 1.15rem, med flytande skalning däremellan baserat på viewport-bredden. Eftersom padding är satt i em växer hela knappen proportionellt med texten. min-height: 44px fungerar som en sista garanti att tryckytan aldrig blir för liten.

Behöver du knappar som fyller hela bredden i ett mobilt läge räcker det med en enkel mediaquery:

@media (max-width: 640px) {
  .btn-responsive {
    width: 100%;
  }
}

Responsiva knappar i CSS-grid och flexbox

Om knapparna sitter i en grupp, till exempel en rad med ”Spara” och ”Avbryt”, är flex-wrap en enkel lösning:

.btn-group {
  display: flex;
  flex-wrap: wrap;
  gap: 0.75rem;
}

På stora skärmar ligger knapparna i rad. Blir det trångt radbryts de automatiskt. Inga mediaqueries behövs.

Tillgänglighet: focus-states och CSS button-beteende

Det här är det moment som många hoppar över, och det märks. Tangentbordsanvändare, personer med motoriska funktionsnedsättningar och alla som navigerar utan mus förlitar sig på tydliga focus-states för att veta var de befinner sig.

Webbläsarnas inbyggda focus-ring ser olika ut överallt och tas ofta bort med outline: none — utan att ersättas med något bättre. Gör inte det. Använd istället :focus-visible, som bara aktiveras vid tangentbordsnavigering och låter musklickare vara ifred:

.btn:focus-visible {
  outline: 3px solid #93c5fd;
  outline-offset: 2px;
}

outline-offset skapar ett litet mellanrum mellan knappen och ringen, vilket gör den mer synlig och snyggare. Och eftersom vi inte rör outline vid :focus utan specifikt :focus-visible slipper du den blå ringen vid vanliga musklick — vilket var anledningen till att folk tog bort den från början.

Se också till att kontrastförhållandet mellan knappens text och bakgrund klarar WCAG AA, det vill säga minst 4.5:1 för normal text. Vit text på #2563eb klarar det med marginal, men om du väljer ljusare nyanser är det värt att dubbelkolla med ett verktyg som WebAIM Contrast Checker. Det gäller inte bara textfärgen — även hover-states och focus-ringen ska vara tillräckligt synliga mot bakgrunden de renderas på.

Glöm inte disabled-state

En knapp som inte går att klicka ska se ut som att den inte går att klicka:

.btn:disabled {
  opacity: 0.5;
  cursor: not-allowed;
  pointer-events: none;
}

pointer-events: none förhindrar alla musinteraktioner, och opacity: 0.5 ger en tydlig visuell signal. Kombinationen gör att hover-effekterna inte aktiveras av misstag.

Sammanfattning

CSS-knappar kräver mer omsorg än de flesta ger dem. Här är det viktigaste att ta med sig:

Använd em-baserade mått för padding och clamp() för fontstorlek — det ger dig responsiva knappar utan onödiga mediaqueries. Lägg alltid till hover- och active-states med subtila övergångar. Implementera :focus-visible med en tydlig outline för tangentbordsnavigering, det är inte valfritt. Sätt min-height: 44px för att garantera tillräcklig tryckyta på touchenheter. Och slutligen: börja med en transparent border redan i grundstilen, så slipper du layoutskift när du lägger till synliga ramar i andra states.

Med de här teknikerna på plats har du CSS-knappar som ser professionella ut, fungerar överallt och inte stänger ute någon. Det är ren CSS — inga ramverk behövs. Och nästa gång du ser en <button> utan hover-state eller focus-ring vet du exakt vad som saknas.

Inlägget CSS-knappar: skapa snygga och responsiva knappar med ren CSS dök först upp på MONC.

Här förklarar vi vad localhost är, hur det fungerar på nätverksnivå, och hur du använder det praktiskt för lokal webbutveckling.

Localhost förklarat

Localhost är ett värdnamn som alltid pekar tillbaka på din egen dator. Det är nätverkets motsvarighet till ”jag själv”. När du skriver http://localhost i webbläsaren skickar datorn inte iväg någon förfrågan ut på internet — den pratar med sig själv.

Tekniskt sett är localhost mappat till IP-adressen 127.0.0.1 (för IPv4) och ::1 (för IPv6). Det definieras i operativsystemets hosts-fil och i nätverksstandarden RFC 5735. Hela IP-intervallet 127.0.0.0/8 — det vill säga alla adresser från 127.0.0.1 till 127.255.255.254 — är reserverat för loopback, men i praktiken används nästan uteslutande 127.0.0.1.

Loopback-interfacet

Trafik till localhost passerar aldrig nätverkskortet. Operativsystemet fångar upp den via ett virtuellt nätverksinterface som kallas loopback (ofta lo på Linux/Mac). Det innebär att localhost fungerar även utan internetanslutning — du behöver ingen wifi eller nätverkskabel för att köra en lokal utvecklingsserver.

Det innebär också att localhost-trafik inte är synlig för andra enheter på ditt nätverk. Din kollega kan inte nå din lokala server via 127.0.0.1 — den adressen pekar på deras dator, inte din. Vill du dela din lokala server med andra på samma nätverk behöver du binda den till 0.0.0.0 eller din lokala IP-adress.

Portar — localhost:3000, localhost:8080

Du har förmodligen sett adresser som localhost:3000 eller localhost:8080. Siffran efter kolonet är ett portnummer. Portar fungerar som dörrarna till din dator — varje tjänst lyssnar på sin egen port.

Standardportarna som är bra att känna till: port 80 för HTTP, port 443 för HTTPS, port 3000 för Node.js-servrar (Express, Next.js), port 5173 för Vite, port 8000 för Python/Django, port 8080 för diverse Java-baserade servrar.

Varför inte bara använda port 80? Två skäl: portar under 1024 kräver administratörsbehörighet på de flesta system, och du vill kunna köra flera servrar samtidigt — frontend på port 5173 och backend-API på port 3000, till exempel.

Lösa portkonflikter

En av de vanligaste frustreringarna vid lokal utveckling är felmeddelandet ”port already in use”. Det betyder att en annan process redan lyssnar på den porten. På Mac och Linux hittar du den med:

lsof -i :3000

Det listar alla processer som använder port 3000. Avsluta processen med kill -9 PID (där PID är processens ID) eller byt port i din utvecklingsserver.

Lokal server — varför räcker det inte att öppna HTML-filer?

Du kan visserligen öppna en HTML-fil direkt i webbläsaren via file:///, men det fungerar dåligt för allt utom de enklaste sidorna. Webbläsare begränsar vad som får göras från file://-protokollet — JavaScript-moduler laddas inte, fetch()-anrop blockeras av CORS, och relativa sökvägar beter sig annorlunda.

En lokal utvecklingsserver löser allt detta. Den serverar filerna via HTTP precis som en riktig webbserver, vilket betyder att allt beter sig som det kommer att göra i produktion.

Det enklaste sättet att starta en lokal server beror på ditt verktygsval:

# Python (finns förinstallerat på Mac/Linux)
python3 -m http.server 8000

# Node.js med npx (kräver Node)
npx serve

# PHP
php -S localhost:8000

# Vite (för moderna JS-projekt)
npm create vite@latest
npm run dev

Pythons http.server är det snabbaste sättet att servera statiska filer — det kräver inga beroenden utöver en Python-installation. Vite ger dig hot module replacement (HMR) som automatiskt uppdaterar sidan i webbläsaren när du sparar en fil.

HTTPS på localhost

Vissa API:er och webbläsarfunktioner kräver HTTPS — geolocation, service workers och kamera/mikrofon fungerar bara över säkra anslutningar. Men localhost har ett specialundantag: de flesta webbläsare behandlar det som en ”secure context” även utan HTTPS.

Behöver du ändå HTTPS lokalt — exempelvis för att testa med en extern tjänst som kräver det — är mkcert det enklaste verktyget:

mkcert -install
mkcert localhost

Det skapar ett lokalt CA-certifikat och genererar ett giltigt TLS-certifikat för localhost. Din webbläsare litar på det automatiskt, utan varningar.

Localhost vs 0.0.0.0

En viktig skillnad som ofta skapar förvirring: en server som lyssnar på localhost (127.0.0.1) accepterar bara anslutningar från din egen dator. En server som lyssnar på 0.0.0.0 accepterar anslutningar från alla nätverksinterface — inklusive andra enheter på ditt lokala nätverk.

Det spelar roll om du vill testa din sida på en mobil. Binder du servern till 0.0.0.0 kan du öppna din dators lokala IP-adress (t.ex. 192.168.1.42:3000) på telefonen och se sidan. Din lokala IP hittar du med ifconfig (Mac/Linux) eller ipconfig (Windows).

Localhost och miljövariabler

I de flesta projekt vill du att koden beter sig olika lokalt jämfört med produktion — annan databasadress, andra API-nycklar, debug-läge på. Miljövariabler och .env-filer löser det:

# .env (lokal utveckling)
DATABASE_URL=postgresql://localhost:5432/myapp_dev
API_BASE_URL=http://localhost:3000/api
DEBUG=true

Verktyg som dotenv (Node.js) eller python-dotenv (Python) läser .env-filen automatiskt vid uppstart. Se till att .env ligger i .gitignore — den ska aldrig pushas till version control, särskilt inte med produktionslösenord.

Sammanfattning

Localhost (127.0.0.1) är ett värdnamn som pekar tillbaka på din egen dator via loopback-interfacet. Trafiken lämnar aldrig din maskin och fungerar utan internetanslutning. Portar identifierar vilken tjänst du pratar med — localhost:3000 är inte samma sak som localhost:8080. Alltid kör en lokal utvecklingsserver istället för att öppna filer via file:// — det undviker CORS-problem och säkerställer att allt beter sig som i produktion. Och om du behöver dela din lokala server med andra enheter, bind den till 0.0.0.0 istället för 127.0.0.1.

Inlägget Vad är localhost – och hur använder du det för webbutveckling? dök först upp på MONC.

Här går vi igenom hur responsiv design fungerar i praktiken, vilka CSS-verktyg du har att arbeta med, och varför mobile first-strategin fortfarande gäller.

Hur responsiv design fungerar

Kärnan i responsiv webbdesign är tre saker: flexibla layouter, flexibla bilder och mediaqueries. Begreppet myntades av Ethan Marcotte 2010, och grundprinciperna håller fortfarande — även om verktygslådan har vuxit enormt sedan dess.

Viewport-metataggen är startpunkten. Utan den behandlar mobila webbläsare sidan som om den vore designad för desktop och krymper ner den:

<meta name="viewport" content="width=device-width, initial-scale=1" />

Den raden säger: ”Gör viewportens bredd lika med enhetens bredd, och starta utan zoom.” Det är en rad som måste finnas i <head> på varje responsiv sida.

Mobile first — varför du bör börja litet

Mobile first innebär att du designar och kodar för den minsta skärmen först, och sedan lägger till komplexitet för större skärmar med min-width-mediaqueries. Det låter kontraintuitivt, men det tvingar dig att prioritera innehåll och funktion — du kan inte gömma problem bakom en bredare yta.

/* Basstil: gäller alla skärmstorlekar (mobil först) */
.container {
  padding: 1rem;
}

.card-grid {
  display: grid;
  grid-template-columns: 1fr;
  gap: 1rem;
}

/* Surfplatta och uppåt */
@media (min-width: 768px) {
  .container {
    padding: 2rem;
  }

  .card-grid {
    grid-template-columns: repeat(2, 1fr);
    gap: 1.5rem;
  }
}

/* Desktop */
@media (min-width: 1024px) {
  .container {
    max-width: 1200px;
    margin: 0 auto;
  }

  .card-grid {
    grid-template-columns: repeat(3, 1fr);
  }
}

Basstilen med 1fr ger en enda kolumn på mobil. Vid 768px går vi till två kolumner, vid 1024px till tre. max-width och margin: 0 auto centrerar innehållet på breda skärmar.

En vanlig fråga är vilka breakpoints man ska använda. Det finns inga universella svar, men 640px (stor telefon), 768px (surfplatta), 1024px (liten laptop) och 1280px (desktop) är rimliga utgångspunkter. Det viktigaste är att breakpoints baseras på var din layout behöver ändras, inte på specifika enhetsmodeller — nya enheter släpps hela tiden med nya skärmstorlekar.

Responsiva enheter: rem, em, vw och clamp()

Pixlar är fasta. Responsiv design kräver relativa enheter som skalas med sitt sammanhang:

rem är relativ till root-elementets fontstorlek (oftast 16px). 1.5rem är alltid 24px oavsett var i dokumentet du befinner dig. em är relativ till förälderns fontstorlek. 1.5em på ett element inuti en <h2> med font-size: 20px blir 30px. vw och vh är relativ till viewportens bredd respektive höjd. 1vw = 1% av viewport-bredden.

clamp() kombinerar allt och ger dig responsiva värden utan mediaqueries:

h1 {
  font-size: clamp(1.75rem, 1.5rem + 1.5vw, 3rem);
}

.section {
  padding: clamp(1.5rem, 3vw, 4rem);
}

clamp() tar tre värden: minimum, önskat värde och maximum. Texten skalas flytande med viewport-bredden men går aldrig under 1.75rem eller över 3rem. Det eliminerar behovet av mediaqueries för typografi och spacing.

Responsiva bilder

Bilder som inte anpassar sig är det snabbaste sättet att förstöra en mobilupplevelse. Den grundläggande regeln är enkel:

img {
  max-width: 100%;
  height: auto;
}

Men det räcker inte alltid. En 2000px bred hero-bild som krymps till 375px med CSS laddas fortfarande i full storlek — det är slöseri med data och bandbredd. HTML:s srcset-attribut löser det:

<img
  src="hero-800.jpg"
  srcset="hero-400.jpg 400w, hero-800.jpg 800w, hero-1600.jpg 1600w"
  sizes="(max-width: 600px) 100vw, (max-width: 1024px) 80vw, 1200px"
  alt="Beskrivning av bilden"
/>

Webbläsaren väljer rätt bildstorlek baserat på viewport-bredden och enhetens pixeldensitet. På en iPhone med 375px viewport och 3x pixeldensitet behövs en bild som är 375 × 3 = 1125 pixlar bred — webbläsaren väljer automatiskt hero-1600.jpg från listan.

Responsiv typografi

Textstorlek som är behaglig på desktop kan vara för stor eller för liten på mobil. clamp() är det moderna svaret, men du kan också använda en enkel skala med mediaqueries:

:root {
  font-size: 100%; /* 16px */
}

body {
  font-size: 1rem;
  line-height: 1.7;
}

@media (min-width: 1024px) {
  :root {
    font-size: 112.5%; /* 18px */
  }
}

Genom att ändra root-fontstorleken skalas allt som använder rem automatiskt. Det ger dig en global typografisk kontroll med en enda ändring.

Container queries — nästa steg i responsiv design

Mediaqueries utgår alltid från viewportens bredd. Men vad händer när samma komponent används i en bred huvudkolumn och i en smal sidebar? Med mediaqueries måste du hårdkoda breakpoints per kontext. Container queries löser det:

.card-container {
  container-type: inline-size;
}

.card {
  display: grid;
  grid-template-columns: 1fr;
}

@container (min-width: 400px) {
  .card {
    grid-template-columns: 150px 1fr;
  }
}

Istället för att fråga ”hur bred är viewporten?” frågar regeln ”hur bred är min container?” Det betyder att kortet automatiskt byter layout beroende på var det placeras — bredvid en sidebar blir det stående, i en fullbreddsektion blir det liggande. Samma komponent, inget duplicerat CSS.

Container queries stöds i alla moderna webbläsare sedan 2023 och är redo för produktion.

Testa responsivitet

Chrome DevTools responsivläge (Ctrl+Shift+M) låter dig simulera olika enheter och skärmstorlekar. Men simulering ersätter inte riktiga enheter — touch-interaktioner, skärmläsare och verklig nätverksprestanda beter sig annorlunda.

Använd också Lighthouse i DevTools för att kontrollera att viewport-metataggen finns, att texten är läsbar utan zoom och att tryckytor är tillräckligt stora.

Sammanfattning

Responsiv webbdesign handlar om att bygga sidor som fungerar på alla skärmstorlekar. Börja med viewport-metataggen och en mobile first-strategi. Använd CSS Grid och Flexbox med relativa enheter istället för fasta pixelvärden. clamp() ger dig flytande skalning utan mediaqueries. srcset och sizes ser till att rätt bildstorlek laddas. Och testa alltid på riktiga enheter — simulatorer visar inte hela bilden.

Inlägget Vad är responsiv webbdesign – och varför spelar det roll? dök först upp på MONC.

Att förstå vad webbläsaren faktiskt gör är inte bara akademiskt intressant — det gör dig till en bättre webbutvecklare. Här går vi igenom hela kedjan, från URL till färdig sida.

Steg 1: DNS — hitta serverns adress

När du skriver monc.se i adressfältet behöver webbläsaren först ta reda på vilken IP-adress som hör till domännamnet. Det sker via DNS (Domain Name System), som fungerar som internets telefonkatalog.

Webbläsaren kollar först sin egen cache — har du besökt sidan nyligen finns svaret redan. Därefter frågar operativsystemets cache, sedan din routers cache, och slutligen din internetleverantörs DNS-server. Om ingen har svaret skickas frågan vidare uppåt i DNS-hierarkin tills rätt IP-adress hittas.

Det här steget tar vanligtvis 20–120 millisekunder. Verktyg som dns-prefetch i HTML låter webbläsaren göra DNS-uppslag i förväg för domäner du vet att sidan kommer att behöva, till exempel CDN:er och tredjeparts-API:er.

Steg 2: Anslutning — TCP och TLS

Med IP-adressen i hand upprättar webbläsaren en TCP-anslutning med servern. Det sker via en ”three-way handshake” — tre meddelanden som bekräftar att båda sidor är redo att kommunicera.

Använder sidan HTTPS (vilket i princip alla gör idag) följer en TLS-handshake ovanpå TCP:n. Webbläsaren och servern förhandlar om krypteringsalgoritm, utbyter nycklar och verifierar serverns SSL-certifikat. Först därefter kan data skickas säkert.

HTTP/2 och HTTP/3 har optimerat den här processen avsevärt. HTTP/2 multiplexar flera förfrågningar över en enda anslutning, och HTTP/3 använder QUIC-protokollet som bygger på UDP istället för TCP, vilket minskar antalet roundtrips som krävs.

Steg 3: HTTP-förfrågan och svar

Webbläsaren skickar en HTTP GET-förfrågan till servern med information om vilken resurs den vill ha, vilken webbläsare som frågar och vilka format den accepterar. Servern svarar med en statuskod (200 OK om allt gick bra), HTTP-headers med metadata, och själva HTML-dokumentet.

Headers innehåller viktig information: Content-Type som talar om att svaret är HTML, Cache-Control som styr hur länge resursen får cachas, och Content-Encoding som anger eventuell komprimering (vanligtvis gzip eller Brotli).

Caching spelar en stor roll för prestanda. Om webbläsaren redan har en cachad version av resursen och servern bekräftar att den inte ändrats (via 304 Not Modified) behöver hela dokumentet inte laddas ner igen. Det är därför en sida ofta laddar betydligt snabbare vid andra besöket — DNS, anslutning och resurser finns redan i cache.

Steg 4: HTML-parsning och DOM-konstruktion

Nu börjar det intressanta. Webbläsaren tar emot HTML-dokumentet som en ström av bytes och börjar parsa det — tecken för tecken, tagg för tagg — till ett DOM-träd (Document Object Model).

DOM:en är en trädstruktur där varje HTML-element blir en nod. <html> är roten, <head> och <body> är barn, och alla element däri grenar vidare neråt. Det är den strukturen som JavaScript sedan interagerar med via metoder som document.querySelector().

Parsningen är inte helt rak. När webbläsaren stöter på en <script>-tagg pausar den HTML-parsningen, laddar ner scriptet och kör det — det kan ju modifiera DOM:en som håller på att byggas. Det är därför <script>-taggar traditionellt placeras precis före </body>, och varför defer-attributet finns: det låter scriptet laddas parallellt men väntar med exekveringen tills HTML:en är färdigparsad.

<link>-taggar till CSS-filer blockerar inte HTML-parsningen men blockerar renderingen — webbläsaren vägrar visa sidan förrän den vet hur den ska se ut. Det kallas render-blocking, och det är anledningen till att stora, ooptimerade CSS-filer kan fördröja den första visuella rendringen avsevärt.

Moderna webbläsare har en ”preload scanner” som tittar framåt i HTML:en medan parsern är blockerad, och börjar ladda resurser den vet kommer att behövas — CSS-filer, bilder och scripts. Det är en optimering som sker automatiskt och gör stor skillnad i praktiken.

Steg 5: CSSOM — webbläsarens stilberäkning

Parallellt med DOM-konstruktionen bygger webbläsaren ett CSSOM (CSS Object Model) från alla stilmallar. Varje CSS-regel parsas, specificitet beräknas, och arv appliceras. Resultatet är en fullständig stilbeskrivning för varje element i DOM:en.

Det är i det här steget som CSS cascading, specificitet och arv spelar ut — webbläsaren avgör vilka regler som gäller för varje element baserat på de principer vi beskrivit i andra artiklar.

Steg 6: Render tree, layout och paint

Med DOM:en och CSSOM på plats kombinerar webbläsaren dem till ett render tree — en träd-struktur som bara innehåller synliga element med deras beräknade stilar. Element med display: none finns i DOM:en men inte i render tree.

Layout-steget (ibland kallat ”reflow”) beräknar varje elements exakta position och storlek på skärmen. Det är här som CSS-värden som width: 50%, margin: auto och flex: 1 omvandlas till konkreta pixelvärden.

Paint-steget konverterar render tree till faktiska pixlar. Webbläsaren ritar text, färger, bilder, ramar och skuggor för varje element. Och slutligen, i compositing-steget, läggs alla lager ihop till den slutliga bilden som visas på skärmen.

Varför det spelar roll för prestanda

Varje förändring du gör på sidan triggar potentiellt delar av den här kedjan igen. Ändrar du en elements width i JavaScript triggar det layout (reflow), paint och compositing. Ändrar du color triggar det paint och compositing men inte layout. Ändrar du transform eller opacity triggar det bara compositing — det billigaste steget.

Det är därför CSS-animationer med transform och opacity är så mycket snabbare än animationer med top, left, width eller height. De sista fyra triggar layout-omberäkning för varje animationsframe, medan de första två hanteras helt av GPU:n.

Några praktiska konsekvenser: undvik att ändra layout-triggande egenskaper i animationer. Använd will-change: transform för att hinta till webbläsaren att ett element kommer att animeras. Och batchera DOM-ändringar istället för att göra dem en åt gången — varje enskild ändring kan trigga en ny layout-beräkning.

Webbläsarens utvecklingsverktyg

Chrome DevTools Performance-panelen visualiserar hela render-pipelinen. Du kan se exakt hur lång tid varje steg tar — parsning, stilberäkning, layout, paint, compositing — och identifiera flaskhalsar. Network-panelen visar DNS-uppslag, anslutningar och varje enskild resurs som laddas, med timing för varje fas.

Det är en av de mest kraftfulla resurserna du har som webbutvecklare, och det är gratis.

Sammanfattning

En webbläsare gör enormt mycket arbete på under en sekund. DNS löser domännamnet till en IP-adress. TCP och TLS upprättar en säker anslutning. HTTP hämtar HTML-dokumentet. Parsern bygger DOM och CSSOM. Render tree, layout och paint producerar de pixlar du ser. Och varje förändring du gör med JavaScript eller CSS triggar delar av kedjan igen — det är därför prestanda-medveten utveckling handlar om att förstå vilka steg som triggas och minimera onödigt arbete.

Inlägget Hur fungerar en webbläsare – från URL till färdig sida dök först upp på MONC.

Här förklarar vi vad en API är, hur den fungerar tekniskt, och varför det är ett av de viktigaste koncepten att förstå som webbutvecklare.

API förklarat — vad det faktiskt innebär

API står för Application Programming Interface. Det är ett gränssnitt som låter två program prata med varandra enligt överenskomna regler. Istället för att en människa klickar sig igenom ett webbgränssnitt kan ett program skicka en strukturerad förfrågan och få ett strukturerat svar tillbaka.

Tänk på det som en kontraktsspecifikation. API:et säger: ”Om du skickar mig den här typen av förfrågan, med de här parametrarna, så ger jag dig tillbaka den här typen av svar.” Det är allt — ett avtal om hur kommunikationen ska se ut.

Det finns API:er överallt. Varje gång en mobilapp hämtar data från en server, varje gång du loggar in med Google på en tredjepartssajt, varje gång en webshop beräknar fraktkostnad via PostNord — det går via ett API.

Hur fungerar ett REST API?

REST (Representational State Transfer) är det vanligaste sättet att bygga webb-API:er. Ett REST API använder HTTP — samma protokoll som din webbläsare — och kommunicerar med standardmetoderna GET, POST, PUT och DELETE.

Här är ett konkret exempel. Säg att du bygger en app som hanterar böcker. Ett REST API för den tjänsten kan se ut så här:

GET    /api/books          → Hämta alla böcker
GET    /api/books/42       → Hämta bok med ID 42
POST   /api/books          → Skapa en ny bok
PUT    /api/books/42       → Uppdatera bok 42
DELETE /api/books/42       → Ta bort bok 42

Varje URL (eller ”endpoint”) representerar en resurs, och HTTP-metoden bestämmer vad du vill göra med den. GET hämtar data, POST skapar ny data, PUT uppdaterar befintlig data och DELETE tar bort.

API-svar i JSON

Data som skickas fram och tillbaka är nästan alltid i JSON-format (JavaScript Object Notation). Det ser ut så här:

{
  "id": 42,
  "title": "Norrlands mörker",
  "author": "Stina Jackson",
  "year": 2018,
  "available": true
}

JSON är textbaserat, lättläst för människor och enkelt att tolka för datorer. Det är därför det blivit standardformatet för API-kommunikation.

API-nycklar och autentisering

De flesta API:er kräver någon form av autentisering — du kan inte bara skicka anrop hur som helst. Det vanligaste mönstret är API-nycklar: en unik sträng som identifierar dig och avgör vad du har tillgång till.

GET /api/books
Authorization: Bearer din-api-nyckel-här

API-nyckeln skickas med i varje anrop som en HTTP-header. Servern kontrollerar nyckeln, verifierar att du har rätt att göra den aktuella förfrågan, och returnerar data om allt stämmer.

Andra autentiseringsmetoder inkluderar OAuth (som används när du loggar in med Google eller GitHub) och JWT-tokens (JSON Web Tokens) som är vanliga i moderna webbapplikationer. Gemensamt för alla är att de löser samma grundproblem: vem är du, och vad får du göra?

Varför API:er är viktiga

API:er är limmet i modern webbutveckling. Utan dem skulle varje tjänst vara en isolerad ö. Några vardagliga exempel:

Betalningar: Stripe, Klarna och Swish exponerar API:er som låter din webbshop hantera betalningar utan att du bygger ett eget betalningssystem. Kartor: Google Maps API och Mapbox låter dig bädda in kartor och beräkna rutter. E-post: SendGrid och Mailgun hanterar e-postutskick via API-anrop. Väderdata: SMHI har ett öppet API där du kan hämta prognoser och mätdata gratis.

I alla dessa fall slipper du bygga funktionaliteten själv. Du gör ett API-anrop, får tillbaka data, och använder den i din applikation. Det är kärnan i varför API:er är så centrala — de låter dig stå på andras axlar.

HTTP-statuskoder — API:ets språk

Varje API-svar innehåller en statuskod som talar om vad som hände. De viktigaste att känna till: 200 OK betyder att allt gick bra. 201 Created bekräftar att en ny resurs skapades (efter POST). 400 Bad Request betyder att din förfrågan var felformaterad. 401 Unauthorized att du saknar eller har felaktig autentisering. 404 Not Found att resursen inte existerar. Och 429 Too Many Requests att du skickat för många anrop — de flesta API:er har rate limiting som begränsar antalet anrop per tidsenhet.

Att hantera dessa koder i din kod är grundläggande — du kan inte anta att varje anrop lyckas.

Testa ett API i praktiken

Det enklaste sättet att förstå hur ett API fungerar är att testa ett. SMHIs öppna API kräver ingen registrering:

GET https://opendata-download-metfcst.smhi.se/api/category/pmp3g/version/2/geotype/point/lon/18.07/lat/59.33/data.json

Den URL:en ger dig en väderprognos för Stockholm i JSON-format. Klistra in den i din webbläsare och du ser rå API-data direkt.

Vill du experimentera mer strukturerat är Postman ett populärt verktyg som låter dig bygga och skicka HTTP-förfrågningar visuellt. Du kan testa olika metoder, lägga till headers och se svaren formaterat. Alternativt fungerar curl i terminalen:

curl -s "https://opendata-download-metfcst.smhi.se/api/category/pmp3g/version/2/geotype/point/lon/18.07/lat/59.33/data.json" | head -c 500

REST vs GraphQL vs WebSocket

REST är standard, men det finns alternativ. GraphQL låter klienten specificera exakt vilken data den vill ha — istället för att servern bestämmer vad varje endpoint returnerar. Det minskar problemet med ”överhämtning” av data men lägger till komplexitet.

WebSockets är en annan teknik som ger tvåvägskommunikation i realtid — servern kan skicka data till klienten utan att klienten frågar. Det används för chattappar, live-uppdateringar och multiplayer-spel.

I de flesta projekt börjar du med REST. Det är enklare, välförstått och har bättre verktyg. GraphQL och WebSockets löser specifika problem som du sannolikt inte har från start.

Sammanfattning

En API är ett gränssnitt som låter program kommunicera med varandra. REST API:er använder HTTP-metoder som GET och POST för att hantera resurser, och JSON för att skicka data. Autentisering sker via API-nycklar, OAuth eller JWT-tokens. API:er är grunden för modern webbutveckling — från betalningar och kartor till väderdata och e-post. Och det bästa sättet att lära sig är att testa: öppna SMHIs API i webbläsaren eller installera Postman och börja skicka anrop.

Inlägget Vad är en API – förklarat på svenska utan krångel dök först upp på MONC.