Developer Tools Die Je Dagelijks Nodig Hebt: JSON, Regex en Meer

JSON formatteren en debuggen

JSON is het universele dataformaat van het moderne web. Vrijwel elke API die je aanroept, elke configuratie die je schrijft en elk logbericht dat je leest bevat JSON. En toch is het debuggen van JSON een van de meest voorkomende frustraties in het dagelijks werk van een developer.

Het probleem begint bij ongeformatteerde JSON. Een API-response die als een enkele regel binnenkomt, is onleesbaar. Geneste objecten van vijf niveaus diep, arrays met honderden elementen, en geen enkele regelovergang in zicht. Een JSON-formatter zet die brij om in leesbare, netjes geindenteerde structuur.

Maar formatteren is slechts het begin. Het echte nut van een goede JSON-tool zit in validatie. Een ontbrekende komma, een extra komma aan het einde van een array of aanhalingstekens die niet kloppen: het zijn fouten die je met het blote oog nauwelijks ziet maar die je parser laten crashen. Een JSON-formatter markeert de exacte positie van syntaxfouten, waardoor je in seconden vindt waarnaar je anders minuten had gezocht.

Een praktische tip: als je werkt met grote JSON-responses, gebruik dan de zoekfunctie om specifieke keys te vinden in plaats van door de hele structuur te scrollen. En als je regelmatig met dezelfde API werkt, bewaar dan een geformatteerd voorbeeld van de response-structuur. Dat bespaart je elke keer opnieuw uitzoeken hoe de data genest is.

Voor Nederlandse developers die werken met overheids-API's als die van het Kadaster, de KvK of de Belastingdienst: deze API's leveren vaak complexe, diep geneste JSON-structuren. Een goede formatter is daarbij onmisbaar.

Reguliere expressies schrijven en testen

Reguliere expressies, of regex, zijn een van die tools die je niet dagelijks nodig hebt, maar als je ze nodig hebt, zijn ze onvervangbaar. Het valideren van e-mailadressen, het extraheren van datums uit tekst, het zoeken en vervangen met patronen in logbestanden: regex is de oplossing.

Het schrijven van een regex is berucht lastig. De syntax is compact maar cryptisch. Een expressie als ^[A-Z]{2}\d{2}[A-Z0-9]{4}\d{7}([A-Z0-9]{0,16})?$ valideert een IBAN-nummer, maar het kost even om dat te ontcijferen.

Een regex-tester maakt het proces veel draaglijker. Je typt je patroon in, plakt een stukje testtekst erbij en ziet direct welke delen matchen. De meeste testers markeren de matches visueel en tonen de capture groups, zodat je precies ziet wat je expressie doet.

De iteratieve workflow is de sleutel: begin met een simpel patroon dat ruwweg matcht wat je zoekt, en verfijn stap voor stap. Test na elke wijziging met zowel geldige als ongeldige input. Vooral die ongeldige input is belangrijk: een regex die alles accepteert is net zo nutteloos als geen regex.

Veelgebruikte patronen voor Nederlandse data: postcode-validatie (\d{4}\s?[A-Z]{2}), telefoonnummers (die in Nederland verrassend veel variatie kennen), BSN-validatie (9 cijfers met de elfproef) en Nederlandse datumformaten (dd-mm-jjjj in plaats van het Amerikaanse mm/dd/yyyy).

Een tip: als je een complexe regex hebt geschreven die werkt, documenteer hem. Voeg een commentaar toe in je code dat uitlegt wat het patroon doet. Over drie maanden begrijp je je eigen regex niet meer, gegarandeerd.

Encoding en decoding: Base64 en URL-encoding

Encoding is een van die concepten die elke developer begrijpt maar waar regelmatig verwarring over ontstaat. Base64, URL-encoding, HTML-entities: het zijn allemaal manieren om data om te zetten naar een formaat dat veilig is voor transport of opslag in een bepaalde context.

Base64 is de meest voorkomende. Het zet binaire data om naar ASCII-tekst, wat handig is als je binaire data moet meesturen in een context die alleen tekst verwacht. Denk aan afbeeldingen in e-mail (MIME), certificaten in configuratiebestanden of kleine bestanden in JSON-payloads.

In de dagelijkse praktijk kom je Base64 vooral tegen bij het debuggen. Een API stuurt een veld terug dat Base64-gecodeerd is en je moet weten wat erin zit. Of je moet een bestand Base64-coderen om het mee te sturen in een API-request. Een online Base64-tool maakt dit in seconden duidelijk.

URL-encoding is even alomtegenwoordig. Speciale tekens in URL's moeten gecodeerd worden: een spatie wordt %20, een ampersand wordt %26, enzovoort. Als je URL-parameters debugt die niet werken, is het eerste wat je controleert of de encoding klopt. Vooral bij het doorgeven van zoektermen of filtercriteria via URL-parameters gaat dit regelmatig mis.

Een veelvoorkomende fout bij Nederlandse developers: tekens met accenten en trema's (zoals ë, ü, é) worden bij URL-encoding omgezet naar meerdere bytes vanwege UTF-8. Dit leidt soms tot dubbele encoding als je niet oplet, wat resulteert in onleesbare tekens bij de ontvanger. Decode altijd maar een keer, en codeer altijd maar een keer.

UUID's genereren en kiezen

UUID's (Universally Unique Identifiers) zijn 128-bit identifiers die vrijwel gegarandeerd uniek zijn zonder centrale coördinatie. Ze worden overal gebruikt: als database primary keys, als correlatie-ID's in logging, als sessie-identifiers en als bestandsnamen.

Er zijn verschillende UUID-versies en de keuze maakt uit. UUID v4 is volledig willekeurig en de meest gebruikte versie. Het is simpel en effectief, maar de willekeurigheid heeft een nadeel: ze zijn niet sorteerbaar op tijd. In een database betekent dit dat inserts willekeurig over de index verspreid worden, wat bij grote tabellen de performance kan schaden.

UUID v7 is een nieuwere standaard die dit probleem oplost. De eerste 48 bits bevatten een timestamp, waardoor UUID v7's chronologisch sorteerbaar zijn. Ze zijn daarmee ideaal als database primary key omdat ze de insert-performance van een auto-increment ID benaderen terwijl ze de voordelen van een UUID behouden: geen centrale coördinatie nodig en veilig om naar externe systemen te communiceren.

Voor nieuwe projecten is UUID v7 vrijwel altijd de betere keuze. Voor bestaande systemen die al UUID v4 gebruiken, is migreren meestal niet de moeite waard tenzij je meetbare performance-problemen hebt.

Een UUID-generator is handig bij het ontwikkelen en testen. Als je een API-endpoint test dat een UUID verwacht, of als je testdata moet aanmaken met unieke identifiers, is het sneller om ze online te genereren dan om een script te schrijven. Genereer er een paar, plak ze in je testdata en ga verder.

Overigens: in de Nederlandse tech-community wordt soms gediscussieerd of je UUID's als primary key moet gebruiken of als losse kolom naast een auto-increment ID. Beide benaderingen hebben verdedigers. De trend gaat richting UUID's als primary key, zeker bij microservices-architecturen waar meerdere services onafhankelijk records moeten kunnen aanmaken.

JWT tokens inspecteren en debuggen

JSON Web Tokens (JWT) zijn de standaard voor authenticatie in moderne webapplicaties. Als developer kom je ze dagelijks tegen: in authorization headers, in OAuth-flows en in single sign-on implementaties. En als er iets misgaat met authenticatie, is het inspecteren van het JWT-token de eerste stap in het debuggen.

Een JWT bestaat uit drie delen, gescheiden door punten: de header, de payload en de signature. De header bevat het algoritme en het tokentype. De payload bevat de claims, dat zijn de daadwerkelijke gegevens zoals de gebruikers-ID, de rollen, de uitgiftedatum en de vervaldatum. De signature garandeert dat het token niet is gemanipuleerd.

Bij het debuggen van authenticatieproblemen wil je meestal de payload inspecteren. Is het token verlopen? Klopt de issuer? Zitten de verwachte claims erin? Een JWT-decoder decodeert de Base64url-gecodeerde header en payload en toont ze als leesbare JSON.

Belangrijk: een JWT-decoder verifieert niet de signature. Het token decoderen kan iedereen, dat is by design. De beveiliging zit in de signature-verificatie, die alleen mogelijk is met de geheime sleutel of het publieke certificaat. Gebruik een online decoder dus uitsluitend voor inspectie, niet voor validatie.

Een veelgemaakte fout: JWT-tokens in de browserconsole loggen tijdens development en dat per ongeluk in productie laten staan. In de context van de AVG is dit extra relevant: JWT-tokens bevatten vaak persoonsgegevens (e-mailadres, naam) en het onbedoeld loggen daarvan kan als een datalek worden beschouwd.

Een andere valkuil is het niet controleren van de exp-claim (expiry). Een token dat technisch geldig is maar al uren of dagen verlopen, wordt door de meeste frameworks geweigerd. Als je testomgeving een ander tijdstip hanteert dan je lokale machine, kan dit tot verwarrende fouten leiden. Controleer altijd de exp-claim en vergelijk deze met de huidige tijd in UTC.

Een efficiente developer workflow opbouwen

De tools die hierboven zijn beschreven, vormen samen een toolkit die je als developer vrijwel dagelijks nodig hebt. De sleutel tot efficiëntie is niet zozeer welke tools je gebruikt, maar hoe snel je erbij kunt.

De meeste developers hebben een verzameling bookmarks naar hun favoriete tools. Organiseer die bookmarks in een aparte map in je browser. Nog beter: gebruik een enkele website die al deze tools op een plek aanbiedt, zodat je niet hoeft te onthouden welke tool op welke website staat.

Een browsergebaseerde aanpak heeft voordelen boven geinstalleerde software. Je hoeft niets te installeren of te updaten. De tools werken op elk besturingssysteem. En als je data lokaal wordt verwerkt (zonder upload naar een server), is de privacy gewaarborgd. Dat laatste is relevant als je met productiedata werkt: een JWT-token uit je productie-omgeving wil je niet naar een willekeurige server sturen.

Overweeg ook om je veelgebruikte bewerkingen te automatiseren. Als je dagelijks JSON-responses van dezelfde API moet formatteren, maak dan een simpel shellscript met jq of een VS Code snippet. Als je regelmatig dezelfde regex-patronen nodig hebt, bewaar ze in een cheatsheet naast je code.

Voor developers in Nederland en Europa is het goed om te weten dat browsergebaseerde tools die data lokaal verwerken, geen AVG-implicaties hebben. Er worden immers geen gegevens naar een derde partij gestuurd. Dit maakt ze veiliger dan clouddiensten, zeker als je werkt met data van klanten of gebruikers.

Tot slot: investeer in het leren van je tools. Een half uur besteden aan het begrijpen van regex-syntax bespaart je uren aan trial-and-error. Het leren van jq-queries voor JSON-manipulatie op de command line maakt je direct productiever. En het begrijpen van hoe JWT werkt, niet alleen hoe je het decodeert maar ook hoe signing en verificatie werken, maakt je een betere developer.