Douglas Crockford en JSON: waarom bijna elke app het gebruikt

JSON in gewone taal: wat het is en waarom het ertoe doet

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.”

Een klein voorbeeld

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.

Wat je uit dit artikel haalt

Je leert:

• Waar JSON vandaan komt en hoe het mainstream werd (inclusief de rol van Douglas Crockford)
• Waarom het "minimalistische" ontwerp een groot deel van het succes verklaart
• Waarom JSON zo natuurlijk past bij API's en HTTP
• Praktische richtlijnen om JSON goed te gebruiken—zodat payloads begrijpelijk blijven naarmate je app groeit

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.

De rol van Douglas Crockford bij het populair maken van JSON

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.

Het probleem in de vroege webperiode: gegevensuitwisseling was rommelig

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 naam, documentatie en “die ene pagina waar je naar kunt wijzen”

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.

Standaardisatiemijlpalen waarop mensen konden vertrouwen

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:

• RFC 4627 (2006): vroege formele beschrijving voor interoperabele implementaties
• ECMA-404: een beknopte standaard die de JSON-syntaxis definieert
• RFC 7159 en later RFC 8259 (2017): verduidelijkten interoperabiliteit en verstevigden JSON's plaats op het internet

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).

Voor JSON: gegevensformaten waarmee het web probeerde te leven

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.

Wat men gebruikte vóór JSON

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 pijnpunten waar teams steeds tegenaan liepen

De veelvoorkomende problemen waren geen theorie:

• Omslachtigheid: XML liet kleine payloads groot lijken, en grote payloads enorm.
• Parse-complexiteit: Real-world XML vereiste vaak zwaardere parsers en zorgvuldige behandeling van namespaces, attributen versus elementen en whitespace.
• Inconsistente conventies: Met ad‑hoc-formaten werd elk endpoint z’n eigen mini-protocol. Clients moesten types, encodering en randgevallen raden.

Waarom “goed genoeg en simpel” wint

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.

Een korte vergelijking: XML versus JSON

<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.

Waarom JSON minimalistisch is: de ontwerpskeuzes die werkten

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.

De kleinste nuttige set bouwstenen

JSON geeft je een minimaal gereedschap dat goed aansluit bij hoe de meeste apps over data denken:

• Objecten: benoemde velden (zoals een contact met name, email)
• Arrays: geordende lijsten (zoals items in een winkelmand)
• Strings: tekst
• Nummers: numerieke waarden (met een paar kanttekeningen)
• Booleans: true/false
• null: een expliciete "geen waarde"

Dat is het. Geen datums, geen comments, geen aangepaste numerieke types, geen verwijzingen. Deze eenvoud maakt JSON gemakkelijk te implementeren in verschillende talen en platforms.

Menselijk leesbaar, machinevriendelijk—opzettelijk

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).

Striktheid is een feature, geen beperking

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.

Een misvatting die het waard is op te helderen

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.

Hoe JSON de standaard werd tussen frontends en backends

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.

JavaScript stond al op elke pagina

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
}

Gemakkelijk parsen overal, niet alleen in browsers

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.

Tooling vermenigvuldigde zich tot een standaardkeuze

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.

Eén payload, veel consumenten

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 en API's: de praktische match met HTTP

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.

HTTP + JSON in één minuut

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/json

Die 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.

Veelvoorkomende API-responsepatronen

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.

JSON versus XML: waarom JSON meestal wint voor app-data

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.

Leesbaarheid en grootte: minder tags, minder ruis

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.

Afstemming met datamodel: kaarten en lijsten passen bij app-data

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).

Waar XML nog steeds kan uitblinken

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.

Richtlijn: kies op basis van behoeften, niet trends

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-regels die teams nog steeds verrassen

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.

De strikte syntaxisregels

Een paar "het werkt op mijn machine"-issues duiken steeds weer op:

• Dubbele aanhalingstekens zijn verplicht voor keys en stringwaarden. {name: "Ada"} is geen JSON; { "name": "Ada" } wel.
• Geen trailing commas. { "a": 1, } zal in veel parsers falen.
• Geen comments. // 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.

Nummers, datums en decimalen: kies types bewust

JSON heeft maar één numeriek type: number. Er is geen ingebouwd integer-, decimaal- of datumtype.

• Geld en hoge-precisie decimalen (prijzen, wisselkoersen) zijn vaak veiliger als strings (bijv. "19.99") om afrondingsverschillen tussen systemen te vermijden.
• Datums en tijden moeten meestal strings zijn in een standaardformaat, meestal ISO 8601 (bijv. "2025-12-26T10:15:30Z"). Vermijd aangepaste datumformaten die gissingen vereisen.
• Wees voorzichtig met zeer grote gehele getallen: sommige omgevingen kunnen ze niet precies representeren. Als je twijfelt, stuur ze als strings.

Unicode en escaping in echte systemen

JSON is Unicode, maar echte systemen struikelen nog steeds over encodering en escaping:

• Zorg dat alles consistent UTF-8 is over het netwerk.
• Onthoud dat bepaalde tekens in strings ontsnapt moeten worden (zoals aanhalingstekens " en backslashes \\).
• Let op onzichtbare tekens die uit documenten worden gekopieerd (non-breaking spaces, slimme aanhalingstekens) die parsing kunnen breken.

Beveiliging: parse JSON veilig

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.

JSON-payloads ontwerpen die goed blijven werken

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.

Consistentie verslaat slimmigheid

Kies naamgevingsregels en houd je eraan:

• Gebruik één casing-stijl (vaak camelCase of snake_case) en meng ze niet.
• Houd keys stabiel. Het hernoemen van userId naar id is een breaking change, ook al voelt de betekenis “evident”.
• Geef de voorkeur aan expliciete velden boven "magische" polymorfie. Een sleutel die van type verandert ("count": 3 vs "count": "3") veroorzaakt moeilijk te traceren bugs.

Versiebeheer zonder drama

Je kunt de meeste versieoorlogen vermijden door wijzigingen additief te maken:

• Voeg nieuwe optionele velden toe in plaats van bestaande te wijzigen of te verwijderen.
• Behandel verwijderingen als deprecations: behoud het oude veld, stop met het documenteren voor nieuwe clients en kondig een verwijderdatum aan.
• Als je echt een breaking change nodig hebt, versioneer het endpoint (/v2/...) of zet een duidelijke versiesignalering in een header—verander semantics niet stilletjes.

Fouten moeten voorspelbaar en saai zijn

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" }
  }
}

Documentatie die de realiteit weergeeft

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.

Waar Koder.ai past (als je snel API's bouwt)

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.

Validatie en contracten: JSON Schema en verder

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.

Waarom validatie ertoe doet (zelfs voor "simpele" JSON)

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: wat het is en wanneer te gebruiken

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:

• Je meerdere clients hebt (web + mobiel + partners) die dezelfde API consumeren
• Je backward-compatible wijzigingen over tijd nodig hebt
• Je automatische checks in CI/CD wilt, niet alleen handmatige review

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.

Lichtere alternatieven (en aanvullingen)

Niet elk team heeft direct volledige schema-tooling nodig. Praktische opties zijn:

• Gedeelde voorbeeldpayloads in de repo (golden files)
• Contracttests die echte responses tegen verwachtingen verifiëren
• Consumer-driven contracts (clients definiëren wat ze nodig hebben)

Een nuttige vuistregel: begin met voorbeelden en contracttests, en voeg JSON Schema toe zodra integraties en wijzigingen zich opstapelen.

Prestaties en betrouwbaarheid met JSON op schaal

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.

Houd payloads klein: pagineer, filter en voorkom overfetching

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.

Compressie en caching: minder bytes, minder verzoeken

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:

• Cachebare responses voor data die niet elke seconde verandert
• Duidelijke cache-regels (bijv. ETag of "last modified")

Dit vermindert herhaalde downloads en dempt pieken in verkeer.

Streaming en incrementele parsing (als JSON heel groot wordt)

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.

Observeerbaarheid: log veilig zonder data te lekken

JSON is makkelijk te loggen, wat zowel nuttig als gevaarlijk is. Behandel logs als een productoppervlak:

• Log standaard niet hele request/response-bodies
• Redacteer gevoelige velden (tokens, wachtwoorden, persoonsgegevens)
• Geef de voorkeur aan gestructureerde logs met IDs, timing en foutcodes boven ruwe payloads

Goed gedaan, debug je sneller en verlaag je het risico op onbedoelde datalekken.

Wat volgt voor JSON en een simpele checklist met best practices

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.

Waar JSON heen gaat

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.

Verwante formaten: JSON Lines / NDJSON

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.

Een eenvoudige checklist voor best practices

Gebruik dit als een korte pre-flight check voor payloads die langer moeten blijven dan één sprint:

• Houd keys consistent en voorspelbaar (kies een naamgevingsstijl en houd je eraan).
• Geef de voorkeur aan stabiele identifiers (laat clients niet afhankelijk zijn van arrayposities).
• Gebruik ISO 8601-timestamps (bijv. 2025-12-26T10:15:00Z).
• Maak onderscheid tussen “ontbrekend”, “leeg” en null en documenteer je keuze.
• Versie zorgvuldig (voeg velden toe; verwijder/hernoem alleen met een plan).
• Valideer aan de randen (server-side inputvalidatie; client-side sanity checks).
• Geef behulpzame fouten terug (machine-leesbare codes plus menselijke tekst).

Blijf leren

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.