Hva er JSON? En komplett guide for utviklere

Hvis du har skrevet kode i mer enn en uke, har du nesten helt sikkert støtt på JSON. Det dukker opp overalt — svar fra REST-API-er, konfigurasjonsfiler, databasedokumenter, nettleserlagring, logger. Men hva er det egentlig, og hvorfor ble det formatet som slukte nettet?

JSON står for JavaScript Object Notation. Til tross for navnet er det helt språkuavhengig og har biblioteker i alle store programmeringsspråk. Douglas Crockford formaliserte det på begynnelsen av 2000-tallet som et enklere alternativ til XML for kommunikasjon mellom nettleser og server. Spesifikasjonen er også standardisert som ECMA-404, og den er så liten at den får plass på et visittkort — noe som er en del av grunnen til at den vant.

Hvordan ser JSON egentlig ut?

Her er et JSON-utdrag som representerer et brukerobjekt. Dette ene eksempelet dekker alle seks datatypene JSON støtter:

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

De seks datatypene i JSON

JSON støtter nøyaktig seks verditypes. Det er alt. Denne enkelheten er en feature — du kan lære hele formatet på en ettermiddag.

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

• String — Enhver tekst i doble anførselstegn. "hello", "2024-01-01", "" er alle gyldige strenger.
• Number — Heltall eller flyttall. Ingen forskjell mellom int og float. Merk: NaN og Infinity er ikke gyldige JSON-tall.
• Boolean — true eller false, kun med små bokstaver.
• Null — Representerer "ingen verdi". Nyttig for valgfrie felt som ikke er satt.
• Array — En ordnet liste med verdier. Kan blande typer: [1, "two", true, null] er helt lovlig.
• Object — Et sett med nøkkel–verdi-par. Nøkler må være strenger i doble anførselstegn.

Et ekte API-svar

Slik kan et ekte REST-API-svar se ut når du kaller GET /api/users/42. Legg merke til hvordan det nester objekter og arrayer for å representere rikere 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 kunne få tilgang til alice_devs temainnstilling i JavaScript med user.preferences.theme, eller hente hennes første rolle med user.roles[0]. Den naturlige mappingen til språkets primitiver er nettopp hvorfor JSON føles så enkelt å jobbe med.

JSON-syntaksregler — fellene som tar alle

JSON ser enkelt ut, men har noen få strenge regler. Bommer du på én, feiler hele payloaden i parsingen. Dette er feilene jeg ser oftest:

• Nøkler må ha doble anførselstegn. {"name": "Alice"} er gyldig. {name: "Alice"} er ikke. Dette lurer utviklere som kommer fra JavaScript, hvor objektnøkler uten anførselstegn er greit.
• Ingen etterfølgende komma. {"a": 1, "b": 2,} kaster en parsefeil. JavaScript er tilgivende her; JSON-spesifikasjonen er ikke.
• Ingen kommentarer. // eller /* */-kommentarer finnes ikke i JSON. Trenger du konfigurasjonsfiler med kommentarer, vurder YAML eller TOML i stedet.
• Ingen undefined. JavaScripts undefined finnes ikke i JSON. Bruk null for manglende verdier.
• Strenger må bruke doble anførselstegn. Strenger med enkle anførselstegn som {'key': 'value'} er ugyldig JSON.
• Ingen innledende nuller. 042 er ugyldig. 42 eller 0.42 er greit.

Hvorfor JSON vant nettet

Før JSON regjerte XML. Et typisk XML-API-svar var ordrikt, krevde en ordentlig XML-parser, og føltes som å jobbe mot språket. JSON kunne parses av JavaScripts innebygde JSON.parse() — ingen biblioteker nødvendig. Det var mindre over nettverket, lesbart ved et raskt blikk, og mappet direkte til objektene og arrayene utviklere allerede brukte hver dag.

På slutten av 2000-tallet begynte de fleste offentlige API-er å tilby JSON ved siden av XML. På begynnelsen av 2010-tallet droppet mange XML-støtte helt. I dag er standardantakelsen for ethvert REST-API JSON. Til og med GraphQL, som erstattet REST i mange sammenhenger, bruker fortsatt JSON som svarformat.

JSON defineres også av det det ikke støtter

Noen av JSONs begrensninger er bevisste designvalg som holder det enkelt og interoperabelt:

• Ingen datotype. Datoer er bare strenger. Konvensjonen er ISO 8601-format: "2024-01-15T09:30:00Z".
• Ingen binære data. Filer og bilder Base64-kodes typisk inn i en streng.
• Ingen funksjonsverdier. {"fn": function(){} } er ugyldig. JSON er rene data, aldri kode.
• Ingen duplikate nøkler. Teknisk tillatt av spesifikasjonen, men oppførselen er udefinert. I praksis tar parsere den siste verdien.

Nyttige verktøy for å jobbe med JSON

Her er noen verktøy du kommer til å strekke deg etter konstant når du jobber med JSON: JSON Formatter for å pretty-printe minifiserte svar, JSON Validator for å finne syntaksfeil, JSON Minifier for å komprimere JSON til produksjon, og JSON Path for å spørre dypt nestede data uten å skrive løkker.

Den offisielle spesifikasjonen finnes på json.org og er virkelig verdt å lese — det tar omtrent 10 minutter, og du vil forstå formatet fullstendig. Den formelle IETF-spesifikasjonen er RFC 8259 hvis du noen gang trenger å avgjøre en diskusjon.

Oppsummering

JSON er et lettvekts, menneskelesbart dataformat bygget på seks verditypes: strenger, tall, booleans, null, arrayer og objekter. Det har strenge syntaksregler, men ingen overraskelser når du først kan dem. Grunnen til at det ble allestedsnærværende, er ikke at det er det kraftigste formatet — det er fordi det er det enkleste som dekker 95 % av virkelige databehov. Hvis du bygger noe web-relatert, er det ikke valgfritt å forstå JSON. Det er grunnleggende.