Hoe Douglas Crockford JSON populair maakte en waarom het het standaardformaat werd voor webapps en API's—plus praktische tips om JSON vandaag de dag goed te gebruiken.

JSON (JavaScript Object Notation) is een lichtgewicht manier om gegevens als platte tekst weer te geven met key–value-paren en lijsten.
Als je webapps bouwt—even als je niet veel nadenkt over “gegevensformaten”—dan is JSON waarschijnlijk al de lijm die je product bij elkaar houdt. Het is hoe een frontend om data vraagt, hoe een backend reageert, hoe mobiele apps staat synchroniseren en hoe externe diensten events sturen. Als JSON duidelijk en consistent is, leveren teams sneller; als het rommelig is, duurt elke feature langer omdat iedereen ruziet over wat de data “betekent.”
Hier is een klein JSON-object dat je in één oogopslag kunt lezen:
{
"userId": 42,
"name": "Sam",
"isPro": true,
"tags": ["beta", "newsletter"]
}
Zelfs zonder technische context kun je meestal afleiden wat er gebeurt: een gebruiker heeft een ID, een naam, een statusvlag en een lijst met tags.
Je leert:
Het doel is eenvoudig: je helpen niet alleen te begrijpen wat JSON is, maar waarom bijna elke app het “spreekt” en hoe je de veelvoorkomende fouten voorkomt die teams blijven maken.
Douglas Crockford heeft niet alle ideeën achter JSON uitgevonden, maar hij deed iets even belangrijk: hij maakte een simpel, werkbaar patroon zichtbaar, gaf het een naam en duwde het de mainstream in.
In de beginjaren van webapplicaties moesten teams onhandige opties jongleren om data tussen browser en server te verplaatsen. XML was gebruikelijk maar omslachtig. Aangepaste formaten met delimiters waren compact maar kwetsbaar. JavaScript kon technisch data als code evalueren, maar dat vervaagde de grens tussen “data” en “uitvoerbare script”, wat een recept was voor bugs en beveiligingsproblemen.
Crockford zag een schonere weg: gebruik een kleine subset van JavaScript-literal-syntaxis die betrouwbare platte data kan representeren—objecten, arrays, strings, nummers, booleans en null—zonder extra features.
Een van Crockfords grootste bijdragen was sociaal, niet technisch: hij noemde het JSON (JavaScript Object Notation) en publiceerde heldere documentatie op json.org. Dat gaf teams een gedeelde vocabulaire ("we sturen JSON") en een referentie die kort genoeg was om te lezen en strak genoeg om te implementeren.
Hij promootte ook JSON als een gegevensformaat dat onafhankelijk is van JavaScript als programmeertaal: veel talen konden het parsen en genereren, en het leek vanzelfsprekend op veelvoorkomende datastructuren.
Adoptie versnelt wanneer teams zich veilig voelen om langdurig op een formaat te gokken. JSON kreeg geleidelijk die “veilige keuze”-status door algemeen bekende mijlpalen:
Crockfords pleidooi, gecombineerd met deze standaarden en een groeiend ecosysteem van parsers, hielp JSON van een handige conventie naar de standaard manier waarop apps met elkaar praten—vooral over HTTP-API's (komt later aan de orde in /blog/json-and-apis).
Voordat JSON de standaard werd om data te verplaatsen, gebruikte het web een mix van formaten die of te zwaar, te inconsistent of te op maat waren om goed te schalen binnen teams.
XML was de grote “standaard”keuze. Het werkte in meerdere talen, had tooling en kon geneste structuren representeren. Het bracht ook veel ceremonie met zich mee.
Tegelijkertijd stuurden veel apps data als aangepaste querystrings (vooral bij vroege AJAX-aanvragen): key/value-paren in URL's of POST-bodies. Anderen bedachten ad-hoc tekstformaten—een komma-gescheiden lijst hier, een pijp-gescheiden blob daar—vaak met handgemaakte escape-regels die maar één ontwikkelaar begreep.
De veelvoorkomende problemen waren geen theorie:
De meeste apps hebben geen formaat nodig dat elke mogelijke documentstructuur kan uitdrukken. Ze hebben een voorspelbare manier nodig om objecten, arrays, strings, nummers en booleans te sturen—snel, consistent en met minimale ruimte voor interpretatie. Simpele formaten verminderen het aantal beslissingen (en fouten) dat teams per endpoint moeten nemen.
<user>
<id>42</id>
<name>Ada</name>
<isActive>true</isActive>
</user>
{
"id": 42,
"name": "Ada",
"isActive": true
}
Beide drukken hetzelfde idee uit, maar JSON is gemakkelijker te scannen, makkelijker te genereren en staat dichter bij hoe de meeste applicaties data in geheugen modelleren.
Het blijvende succes van JSON is geen toeval. Het slaagt omdat het doelbewust klein is: net genoeg structuur om echte applicatiegegevens te representeren zonder eindeloze variatie uit te nodigen.
JSON geeft je een minimaal gereedschap dat goed aansluit bij hoe de meeste apps over data denken:
name, email)true/falseDat is het. Geen datums, geen comments, geen aangepaste numerieke types, geen verwijzingen. Deze eenvoud maakt JSON gemakkelijk te implementeren in verschillende talen en platforms.
JSON is leesbaar genoeg om snel in logs en API-responses te scannen, terwijl het voor machines snel te parsen blijft. Het vermijdt extra ceremonie maar houdt duidelijke delimiters ({}, [], :) zodat parsers snel en betrouwbaar kunnen werken.
De afweging is: omdat JSON zo minimaal is, moeten teams conventies afspreken voor zaken als timestamps, geld en identifiers (bijvoorbeeld ISO-8601-strings voor datums).
De strikte regels van JSON (dubbele aanhalingstekens voor strings, geen trailing commas, een kleine vaste set types) verminderen ambiguïteit. Minder ambiguïteit betekent minder "het werkt op mijn machine"-fouten wanneer verschillende systemen data uitwisselen.
JSON lijkt op JavaScript-objectsyntaxis, maar JSON is geen JavaScript. Het is een taalneutraal gegevensformaat met zijn eigen regels, bruikbaar vanuit Python, Java, Go, Ruby en waar dan ook waar consistente serialisatie en interoperabiliteit nodig is.
JSON won niet omdat het het meest feature-rijke formaat was. Het won omdat het paste bij de manier waarop webapps al werden gebouwd: een JavaScript-zware browser die met een server praat via eenvoudige HTTP-verzoeken.
Zodra browsers standaard rond JavaScript draaiden, had de clientzijde een ingebouwde manier om gestructureerde data te representeren: objecten, arrays, strings, nummers, booleans en null. JSON weerspiegelde die primitieven nauw, dus het verplaatsen van data tussen "wat de browser begrijpt" en "wat de server stuurt" voelde natuurlijk.
Vroege Ajax-stijl apps versnelden dit. In plaats van volledige HTML-pagina's terug te geven, kon de server een kleine payload terugsturen die de UI direct kon gebruiken. Een response zoals deze was meteen nuttig:
{
"user": {"id": 42, "name": "Sam"},
"unreadCount": 3
}
Ook al lijkt JSON-syntaxis op JavaScript, het is taalneutraal. Zodra servers en clients in andere talen moesten samenwerken met webfrontends, verschenen JSON-bibliotheken—en werden ze snel standaardgereedschap. Een JSON-string omzetten naar native datastructuren is meestal één functie-aanroep, en JSON genereren is even simpel.
Toen frameworks, API-clients, debuggers, proxies en documentatietools JSON als uitgangspunt namen, veroorzaakte iets anders kiezen wrijving. Ontwikkelaars konden payloads inspecteren in browser-devtools, voorbeelden kopiëren/plakken in tests en vertrouwen op volwassen libraries voor encoding, decoding en foutafhandeling.
Een enkele JSON-response kan een web-UI, een mobiele app, een interne service en een derde-partij integratie bedienen met minimale wijzigingen. Die interoperabiliteit maakte JSON een veilige keuze voor teams die “één backend, veel frontends” bouwen—en hielp het de standaard te worden tussen client en server.
JSON won niet omdat het fancy was—het paste netjes in hoe het web al werkte. HTTP draait om het sturen van een verzoek en het krijgen van een antwoord, en JSON is een gemakkelijke, voorspelbare manier om de "body" van dat antwoord (of verzoek) als gestructureerde data te representeren.
Een API-aanvraag bevat meestal een methode en een URL (bijv. GET /users?limit=20). De server antwoordt met een statuscode (zoals 200 of 404), headers en een optionele body.
Wanneer de body JSON is, is één belangrijke header:
Content-Type: application/jsonDie header vertelt clients hoe ze de bytes moeten interpreteren die ze ontvangen. Aan de inkomende kant (client → server) signaleert Content-Type: application/json "ik stuur JSON", en servers kunnen het consequent parsen.
JSON werkt bijzonder goed voor terugkerende patronen die in veel API's voorkomen.
Pagination wikkelt vaak een lijst in met metadata:
{
"data": [{"id": 1, "name": "A"}],
"pagination": {"limit": 20, "offset": 0, "total": 153}
}
Filtering en sortering gebeuren meestal in de URL-querystring, terwijl de resultaten een JSON-array blijven (of een data-veld). Bijvoorbeeld: GET /orders?status=paid&sort=-created_at.
Foutresponses profiteren van een standaardvorm zodat clients berichten kunnen tonen en retries kunnen afhandelen:
{
"error": {
"code": "invalid_request",
"message": "limit must be between 1 and 100",
"details": {"field": "limit"}
}
}
De praktische match is eenvoudig: HTTP levert transport en betekenis (verben, statuscodes, caching), terwijl JSON een lichtgewicht, mensleesbare structuur voor de data zelf biedt.
Wanneer mensen JSON en XML vergelijken, vergelijken ze vaak eigenlijk “data voor apps” versus “data voor documenten.” Beide formaten kunnen gestructureerde informatie representeren, maar JSON sluit meestal beter aan op wat de meeste applicaties daadwerkelijk verplaatsen: simpele objecten, lijsten, strings, nummers, booleans en null.
XML is bewust omslachtig. Repetitieve opening- en sluitingstags maken payloads groter en lastiger te scannen in logs of netwerkinspecteurs. JSON brengt doorgaans dezelfde betekenis over met minder karakters en minder visuele rommel, wat helpt tijdens debugging en kan bandbreedtekosten op schaal verlagen.
Dit gaat niet alleen over esthetiek: kleinere payloads betekenen vaak snellere overdracht en minder werk voor parsers en proxies.
De meeste app-data ziet er van nature uit als dictionaries (key/value-maps) en arrays (lijsten): een gebruiker met attributen, een bestelling met orderregels, een pagina met componenten. JSON sluit direct aan op dat denkmodel en komt overeen met native datastructuren in JavaScript en de meeste moderne talen.
XML kan dezelfde structuren representeren, maar vereist meestal conventies: attributen versus elementen, herhaalde child-elementen voor lijsten en extra regels voor "wat telt als een nummer" (aangezien alles tekst is tenzij je typetoevoeging doet).
XML blijft sterk voor documentgerichte use-cases: gemengde content (tekst afgewisseld met markup), publicatieworkflows en ecosystemen met volwassen XML-tooling (bijv. bepaalde enterprise-integraties). Als je payload meer op een document lijkt dan op een objectgrafiek, kan XML een goede keuze zijn.
Als je primaire doel het uitwisselen van applicatiegegevens tussen frontend, backend en API's is, is JSON meestal de eenvoudigere en directere keuze. Als je documentmarkup nodig hebt, gemengde content of je integreert in een XML-zwaar domein, kan XML geschikter zijn.
JSON lijkt op "JavaScript-objecten", dus teams denken vaak dat ze het als JavaScript kunnen behandelen. Dáár sluipen bugs binnen: JSON is strikter, kleiner en minder vergevingsgezind.
Een paar "het werkt op mijn machine"-issues duiken steeds weer op:
{name: "Ada"} is geen JSON; { "name": "Ada" } wel.{ "a": 1, } zal in veel parsers falen.// en /* ... */ zijn ongeldig. Als je notities nodig hebt, houd die in documentatie of gebruik tijdens ontwikkeling voorzichtig een apart veld.Deze beperkingen zijn bedoeld: ze houden parsers simpel en consistent over talen heen.
JSON heeft maar één numeriek type: number. Er is geen ingebouwd integer-, decimaal- of datumtype.
"19.99") om afrondingsverschillen tussen systemen te vermijden."2025-12-26T10:15:30Z"). Vermijd aangepaste datumformaten die gissingen vereisen.JSON is Unicode, maar echte systemen struikelen nog steeds over encodering en escaping:
" en backslashes \\).Parse altijd JSON met een echte JSON-parser (JSON.parse of het equivalente in jouw taal). Vermijd eval-achtige benaderingen, ook al lijken die sneller. Valideer inputs aan de randen—vooral bij publieke API's—zodat onverwachte velden of types niet in de businesslogica terechtkomen.
Een JSON-payload is niet alleen "data in transit"—het is een interface op lange termijn tussen teams, systemen en jouw toekomstige zelf. Het verschil tussen een payload die lang blijft werken en één die elk kwartaal herschreven wordt, is meestal saaie discipline: consistentie, zorgvuldige change-management en voorspelbare randgevallen.
Kies naamgevingsregels en houd je eraan:
camelCase of snake_case) en meng ze niet.userId naar id is een breaking change, ook al voelt de betekenis “evident”."count": 3 vs "count": "3") veroorzaakt moeilijk te traceren bugs.Je kunt de meeste versieoorlogen vermijden door wijzigingen additief te maken:
/v2/...) of zet een duidelijke versiesignalering in een header—verander semantics niet stilletjes.Clients gaan het beste met falen om als fouten één voorspelbare vorm hebben:
{
"error": {
"code": "INVALID_ARGUMENT",
"message": "email must be a valid address",
"details": { "field": "email" }
}
}
Goede JSON-docs bevatten echte voorbeelden—zowel geslaagde als mislukte responses—with complete velden. Houd voorbeelden gesynchroniseerd met productiegedrag en geef aan welke velden optioneel, nullable of gedeprécieerd zijn. Als voorbeelden overeenkomen met echte responses, verlopen integraties sneller en breekt er minder.
Als je een vibe-coding workflow gebruikt om snel features op te tuigen, worden JSON-contracten nog belangrijker: snelle iteratie is fantastisch totdat clients en services uit elkaar drijven.
Op Koder.ai genereren teams vaak een React-frontend plus een Go + PostgreSQL-backend en itereren ze API-shapes in planning-modus vóórdat ze ze vastleggen. Features zoals snapshots en rollback helpen wanneer een "kleine" JSON-wijziging toch breaking blijkt, en source code export maakt het makkelijk om het contract in je repo te houden en af te dwingen met tests.
JSON is makkelijk te genereren, en dat is zowel sterkte als valkuil. Als één service "age": "27" (string) stuurt en een andere 27 (number) verwacht, zal niets in JSON dat tegenhouden. Het resultaat is meestal het ergste soort bug: een clientcrash in productie, of een subtiele UI-glitch die alleen bij bepaalde data voorkomt.
Validatie draait om het vangen van slechte of onverwachte data voordat het de consumenten bereikt—je frontend, partnerintegraties, analytics-pijplijn of mobiele apps.
Veelvoorkomende foutpunten zijn ontbrekende verplichte velden, hernoemde keys, verkeerde types en "bijna goede" waarden (zoals datums in inconsistente formaten). Een kleine validatiestap aan de API-rand kan dit van outages veranderen in duidelijke foutmeldingen.
JSON Schema is een standaardmanier om te beschrijven hoe je JSON eruit moet zien: verplichte eigenschappen, toegestane types, enums, patronen en meer. Het is het meest nuttig wanneer:
Met een schema kun je requests op de server valideren, responses in tests valideren en documentatie genereren. Veel teams koppelen het aan OpenAPI, zodat het contract expliciet is in plaats van "tribal knowledge". Als je al developer-docs publiceert, kan het linken van schema-voorbeelden vanuit /docs consistentie helpen bewaren.
Niet elk team heeft direct volledige schema-tooling nodig. Praktische opties zijn:
Een nuttige vuistregel: begin met voorbeelden en contracttests, en voeg JSON Schema toe zodra integraties en wijzigingen zich opstapelen.
JSON voelt "licht" als je een paar velden stuurt. Op schaal—mobiele clients op wankele netwerken, veelverkeer-API's, analytics-zware pagina's—kan JSON een performance- of betrouwbaarheidsprobleem worden als je het niet zorgvuldig vormgeeft en verstuurt.
Het meest voorkomende schaalprobleem is niet het parsen van JSON—het is dat er te veel van wordt gestuurd.
Paginering is de eenvoudige winst: retourneer voorspelbare brokken (bijv. limit + cursor) zodat clients niet duizenden records tegelijk downloaden. Voor endpoints die geneste objecten teruggeven, overweeg partial responses: laat de client alleen opvragen wat hij nodig heeft (selecteer velden of "include"-expansies). Dit voorkomt "overfetching", waar een scherm alleen name en status nodig heeft maar alle historische details en configuratievelden ontvangt.
Een praktische regel: ontwerp responses rond gebruikersacties (wat een scherm nú nodig heeft), niet rond wat je database makkelijk kan joinen.
Als je API grote JSON-responses serveert, kan compressie de overdrachtsgrootte aanzienlijk verlagen. Veel servers kunnen gzip of brotli automatisch aanzetten en de meeste clients verwerken dit zonder extra code.
Caching is de andere hefboom. Streef op hoog niveau naar:
Dit vermindert herhaalde downloads en dempt pieken in verkeer.
Voor zeer grote outputs—exports, eventfeeds, bulk-sync—overweeg streaming responses of incrementele parsing zodat clients niet een heel document in geheugen hoeven te laden voordat ze iets nuttigs kunnen doen. Het is niet nodig voor de meeste apps, maar het is een waardevolle optie wanneer "een grote JSON-blok" timeouts begint te veroorzaken.
JSON is makkelijk te loggen, wat zowel nuttig als gevaarlijk is. Behandel logs als een productoppervlak:
Goed gedaan, debug je sneller en verlaag je het risico op onbedoelde datalekken.
JSON is niet "af"—het is stabiel. Wat nu verandert is het ecosysteem eromheen: betere editors, strengere validatie, veiligere API-contracten en meer tooling die teams helpt onbedoelde breaking changes te vermijden.
JSON zal waarschijnlijk de standaard wire-format blijven voor de meeste web- en mobiele apps omdat het breed ondersteund is, makkelijk te debuggen en goed aansluit op gebruikelijke datastructuren.
De grootste verschuiving is naar getypte API's: teams blijven JSON sturen, maar definiëren het preciezer met tools zoals JSON Schema, OpenAPI en codegenerators. Dat betekent minder "raad de vorm"-momenten, betere autocomplete en eerdere foutdetectie—zonder JSON zelf los te laten.
Als je veel records efficiënt moet sturen of opslaan (logs, analytics-events, exports), is één grote JSON-array onhandig. JSON Lines (ook wel NDJSON) lost dit op door één JSON-object per regel te plaatsen. Het streamt goed, kan regel-voor-regel verwerkt worden en werkt prettig met command-line tooling.
Gebruik dit als een korte pre-flight check voor payloads die langer moeten blijven dan één sprint:
2025-12-26T10:15:00Z).null en documenteer je keuze.Als je dieper wilt gaan, bekijk gerelateerde gidsen op /blog—met name onderwerpen zoals schema-validatie, API-versioning en het ontwerpen van payloads voor lange-termijn compatibiliteit.