Hvad er JSON? En komplet guide til udviklere

Hvis du har skrevet kode i mere end en uge, er du næsten helt sikkert stødt på JSON. Det dukker op alle vegne — svar fra REST-API'er, konfigurationsfiler, databasedokumenter, browserlagring, logs. Men hvad er det helt præcist, og hvorfor blev det formatet, der åd nettet?

JSON står for JavaScript Object Notation. På trods af navnet er det fuldstændig sprogafhængigt og har biblioteker i alle større programmeringssprog. Douglas Crockford formaliserede det i starten af 2000'erne som et enklere alternativ til XML til kommunikation mellem browser og server. Specifikationen er også standardiseret som ECMA-404, og den er så lille, at den kan være på et visitkort — hvilket er en del af grunden til, at den vandt.

Hvordan ser JSON egentlig ud?

Her er et JSON-uddrag, der repræsenterer et brugerobjekt. Dette ene eksempel dækker alle seks datatyper, som JSON understøtter:

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

De seks datatyper i JSON

JSON understøtter præcis seks værdityper. Det er det. Den enkelhed er en feature — du kan lære hele 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 — Enhver tekst i dobbelte anførselstegn. "hello", "2024-01-01", "" er alle gyldige strenge.
• Number — Heltal eller kommatal. Ingen forskel mellem int og float. Bemærk: NaN og Infinity er ikke gyldige JSON-tal.
• Boolean — true eller false, kun med små bogstaver.
• Null — Repræsenterer "ingen værdi". Nyttigt til valgfrie felter, der ikke er sat.
• Array — En ordnet liste af værdier. Kan blande typer: [1, "two", true, null] er helt lovligt.
• Object — Et sæt nøgle–værdi-par. Nøgler skal være strenge i dobbelte anførselstegn.

Et rigtigt API-svar

Sådan kan et ægte REST-API-svar se ud, når du kalder GET /api/users/42. Læg mærke til, hvordan det indlejrer objekter og arrays for at repræsentere rigere 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 tilgå alice_devs temaindstilling i JavaScript med user.preferences.theme, eller hente hendes første rolle med user.roles[0]. Den naturlige mapping til sprogets primitiver er præcis derfor, JSON føles så nemt at arbejde med.

JSON-syntaksregler — faldgruberne, der rammer alle

JSON ser simpelt ud, men har nogle få strenge regler. Ram forkert på én, og hele din payload fejler i parsingen. Det er de fejl, jeg ser oftest:

• Nøgler skal have dobbelte anførselstegn. {"name": "Alice"} er gyldigt. {name: "Alice"} er ikke. Det snyder udviklere, der kommer fra JavaScript, hvor objektnøgler uden anførselstegn er fint.
• Ingen efterfølgende kommaer. {"a": 1, "b": 2,} kaster en parsefejl. JavaScript er tilgivende her; JSON-specifikationen er ikke.
• Ingen kommentarer. // eller /* */-kommentarer findes ikke i JSON. Hvis du har brug for konfigurationsfiler med kommentarer, så overvej YAML eller TOML i stedet.
• Ingen undefined. JavaScripts undefined findes ikke i JSON. Brug null til manglende værdier.
• Strenge skal bruge dobbelte anførselstegn. Strenge med enkelte anførselstegn som {'key': 'value'} er ugyldig JSON.
• Ingen foranstillede nuller. 042 er ugyldigt. 42 eller 0.42 er fine.

Hvorfor JSON vandt nettet

Før JSON var XML konge. Et typisk XML-API-svar var pladskrævende, krævede en rigtig XML-parser, og føltes som at arbejde imod sproget. JSON kunne parses af JavaScripts indbyggede JSON.parse() — ingen biblioteker nødvendige. Det fyldte mindre på ledningen, var læseligt ved et hurtigt kig, og mappede direkte til de objekter og arrays, udviklere allerede brugte hver dag.

I slutningen af 2000'erne begyndte de fleste offentlige API'er at tilbyde JSON ved siden af XML. I starten af 2010'erne droppede mange XML-understøttelse helt. I dag er standardantagelsen for ethvert REST-API JSON. Selv GraphQL, som erstattede REST i mange sammenhænge, bruger stadig JSON som svarformat.

JSON defineres også af, hvad det ikke understøtter

Nogle af JSON's begrænsninger er bevidste designvalg, der holder det simpelt og interoperabelt:

• Ingen datotype. Datoer er bare strenge. Konventionen er ISO 8601-format: "2024-01-15T09:30:00Z".
• Ingen binære data. Filer og billeder Base64-kodes typisk ind i en streng.
• Ingen funktionsværdier. {"fn": function(){} } er ugyldigt. JSON er rene data, aldrig kode.
• Ingen duplikerede nøgler. Teknisk tilladt af specifikationen, men adfærden er udefineret. I praksis tager parsers den sidste værdi.

Nyttige værktøjer til at arbejde med JSON

Her er nogle værktøjer, du konstant vil række ud efter, når du arbejder med JSON: JSON Formatter til at pretty-printe minificerede svar, JSON Validator til at finde syntaksfejl, JSON Minifier til at komprimere JSON til produktion, og JSON Path til at forespørge dybt indlejrede data uden at skrive løkker.

Den officielle specifikation findes på json.org og er virkelig værd at læse — det tager omkring 10 minutter, og du vil forstå formatet helt. Den formelle IETF-specifikation er RFC 8259 hvis du nogensinde skal afgøre en diskussion.

Afrunding

JSON er et letvægts, menneskelæsbart dataformat bygget på seks værdityper: strenge, tal, booleans, null, arrays og objekter. Det har strenge syntaksregler, men ingen overraskelser, når du først kender dem. Grunden til, at det blev allestedsnærværende, er ikke, at det er det mest kraftfulde format — det er fordi det er det simpleste, der dækker 95% af virkelige databehov. Hvis du bygger noget web-relateret, er det ikke valgfrit at forstå JSON. Det er fundamentalt.