Vad är JSON? En komplett guide för utvecklare

Om du har skrivit kod i mer än en vecka har du nästan säkert stött på JSON. Det dyker upp överallt — svar från REST-API:er, konfigurationsfiler, databasdokument, webbläsarlagring, loggar. Men vad är det egentligen, och varför blev det formatet som slukade webben?

JSON står för JavaScript Object Notation. Trots namnet är det helt språkoberoende och har bibliotek i alla större programmeringsspråk. Douglas Crockford formaliserade det i början av 2000-talet som ett enklare alternativ till XML för kommunikation mellan webbläsare och server. Specifikationen är också standardiserad som ECMA-404, och den är så liten att den får plats på ett visitkort — vilket delvis är anledningen till att den vann.

Hur ser JSON egentligen ut?

Här är ett JSON-utdrag som representerar ett användarobjekt. Detta enda exempel täcker alla sex datatyper som JSON stöder:

{
  "name": "Alice",
  "age": 30,
  "score": 98.5,
  "active": true,
  "nickname": null,
  "tags": ["developer", "blogger"],
  "address": {
    "city": "Berlin",
    "country": "Germany"
  }
}

De sex datatyperna i JSON

JSON stöder exakt sex värdetyper. Det är allt. Den enkelheten är en feature — du kan lära dig hela formatet på en eftermiddag.

{
  "string":  "Hello, world",
  "integer": 42,
  "float":   3.14159,
  "boolean": true,
  "nothing": null,
  "array":   [1, "two", false, null],
  "object":  { "nested": true }
}

• String — Valfri text inom dubbla citattecken. "hello", "2024-01-01", "" är alla giltiga strängar.
• Number — Heltal eller flyttal. Ingen skillnad mellan int och float. Obs: NaN och Infinity är inte giltiga JSON-tal.
• Boolean — true eller false, endast med små bokstäver.
• Null — Representerar "inget värde". Användbart för valfria fält som inte satts.
• Array — En ordnad lista av värden. Kan blanda typer: [1, "two", true, null] är helt lagligt.
• Object — En uppsättning nyckel–värde-par. Nycklar måste vara strängar inom dubbla citattecken.

Ett verkligt API-svar

Så här kan ett riktigt REST-API-svar se ut när du anropar GET /api/users/42. Lägg märke till hur det nästlar objekt och arrayer för att representera rikare data:

{
  "id": 42,
  "username": "alice_dev",
  "email": "[email protected]",
  "createdAt": "2023-06-15T09:30:00Z",
  "preferences": {
    "theme": "dark",
    "notifications": true,
    "language": "en"
  },
  "roles": ["user", "editor"],
  "lastLogin": "2024-01-10T14:22:00Z",
  "stats": {
    "postsPublished": 27,
    "commentsWritten": 154,
    "likesReceived": 489
  }
}

Du skulle komma åt alice_devs temainställning i JavaScript med user.preferences.theme, eller hämta hennes första roll med user.roles[0]. Den naturliga mappningen till språkets primitiver är precis varför JSON känns så smidigt att jobba med.

JSON-syntaxregler — fällorna som sätter dit alla

JSON ser enkelt ut men har några strikta regler. Missa en och hela din payload misslyckas att parsas. Det här är misstagen jag ser oftast:

• Nycklar måste ha dubbla citattecken. {"name": "Alice"} är giltigt. {name: "Alice"} är det inte. Detta snubblar utvecklare som kommer från JavaScript där ociterade objektnycklar fungerar.
• Inga efterföljande kommatecken. {"a": 1, "b": 2,} kastar ett parse-fel. JavaScript är förlåtande här; JSON-specifikationen är det inte.
• Inga kommentarer. Kommentarer som // eller /* */ finns inte i JSON. Behöver du kommenterade konfigfiler, överväg YAML eller TOML istället.
• Inget undefined. JavaScripts undefined finns inte i JSON. Använd null för saknade värden.
• Strängar måste använda dubbla citattecken. Strängar med enkla citattecken som {'key': 'value'} är ogiltig JSON.
• Inga inledande nollor. 042 är ogiltigt. 42 eller 0.42 går bra.

Varför JSON vann webben

Före JSON regerade XML. Ett typiskt XML-API-svar var pratigt, krävde en riktig XML-parser, och kändes som att jobba mot språket. JSON kunde parsas av JavaScripts inbyggda JSON.parse() — inga bibliotek behövdes. Det var mindre på nätverket, läsbart vid en snabb blick, och mappade direkt till de objekt och arrayer utvecklare redan använde varje dag.

Mot slutet av 2000-talet började de flesta publika API:er erbjuda JSON vid sidan av XML. I början av 2010-talet slopade många XML-stödet helt. Idag är standardantagandet för vilket REST-API som helst JSON. Till och med GraphQL, som ersatte REST i många sammanhang, använder fortfarande JSON som svarsformat.

JSON definieras också av vad det inte stöder

Vissa av JSON:s begränsningar är avsiktliga designval som håller formatet enkelt och interoperabelt:

• Ingen datumtyp. Datum är bara strängar. Konventionen är ISO 8601-format: "2024-01-15T09:30:00Z".
• Ingen binärdata. Filer och bilder Base64-kodas typiskt in i en sträng.
• Inga funktionsvärden. {"fn": function(){} } är ogiltigt. JSON är ren data, aldrig kod.
• Inga duplicerade nycklar. Tekniskt tillåtet av specifikationen men beteendet är odefinierat. I praktiken tar parsers det sista värdet.

Användbara verktyg för att jobba med JSON

Här är några verktyg du kommer att nå efter konstant när du jobbar med JSON: JSON Formatter för att snyggt formatera minifierade svar, JSON Validator för att hitta syntaxfel, JSON Minifier för att komprimera JSON för produktion, och JSON Path för att fråga djupt nästlade data utan att skriva loopar.

Den officiella specifikationen finns på json.org och är verkligen värd att läsa — det tar ungefär 10 minuter och du kommer förstå formatet helt. IETF:s formella specifikation är RFC 8259 om du någonsin behöver avgöra en debatt.

Avslutningsvis

JSON är ett lättviktigt, människoläsbart dataformat byggt på sex värdetyper: strängar, tal, booleans, null, arrayer och objekt. Det har strikta syntaxregler men inga överraskningar när du väl kan dem. Anledningen till att det blev allestädes närvarande är inte att det är det mest kraftfulla formatet — det är för att det är det enklaste som täcker 95% av verkliga databehov. Om du bygger något webbrelaterat är det inte valfritt att förstå JSON. Det är grundläggande.