Wanneer een server een actie heeft uitgevoerd, maar het resultaat op een andere plek wil tonen, zonder dat de client die actie per ongeluk opnieuw uitvoert, dan komt status 303 in beeld.
Het klinkt als een nichegeval, maar het is een elegante oplossing voor een probleem dat iedereen met formulieren of API’s weleens tegenkomt: het ongewenst herhalen van een POST-verzoek bij het verversen van de pagina.
Wat doet status 303 precies?
De 303 status code zegt: “je verzoek is gelukt, en het resultaat staat op een andere plek, maar vraag dat resultaat voortaan op met een GET.”
Dat laatste is belangrijk. Waar bij een 302 of 307 de methode behouden kan blijven (wat bij een POST tot dubbele invoer leidt), dwingt 303 expliciet een GET af. Dat maakt het gedrag voorspelbaar, en veilig.
Je ziet dit bijvoorbeeld na het verzenden van een formulier. De data wordt via POST verstuurd naar de server, en die reageert met een 303 en een Location:-header. De browser haalt vervolgens via een GET de bedankpagina op. Als de gebruiker daarna de pagina vernieuwt, wordt niet opnieuw geprobeerd het formulier te versturen, iets wat je bij een 302 of 307 niet kunt garanderen.
Waarom is dit relevant?
In traditionele websites werd dit patroon: POST → redirect → GET; al jaren toegepast. Maar bij API’s, headless toepassingen en moderne webapps komt het opnieuw terug. Als je een actie uitvoert en daarna een ander endpoint wilt aanroepen om het resultaat op te halen, is 303 een nette manier om dat af te dwingen.
Zonder 303 wordt het gedrag van clients al snel inconsistent. Sommige volgen een 302 met een GET, anderen niet. En bij 307 blijft de methode juist wél behouden, wat in veel gevallen ongewenst is.
303 zegt: we zijn klaar met de bewerking. Hier is waar je verdergaat.
Hoe herken je een 303 status?
De meeste browsers handelen een 303 redirect geruisloos af. Je merkt het pas als je met tools als DevTools of curl naar de headers kijkt. Daar zie je:
HTTP/1.1 303 See Other
Location: /volgende-pagina
De client voert dan een GET uit naar de opgegeven locatie, ongeacht wat de oorspronkelijke methode was. Dat maakt 303 bijzonder geschikt voor situaties waarin je de logica van actie en resultaat uit elkaar wilt houden.
Wanneer gebruik je 303 in plaats van 302 of 307?
Als je met formulieren werkt, of met API’s die data aanmaken of bewerken, is 303 vaak precies wat je nodig hebt. Het voorkomt dat gebruikers per ongeluk data twee keer verzenden, en het maakt het gedrag van clients voorspelbaarder.
Bij 302 laat je te veel over aan de interpretatie van de client. Bij 307 ben je juist té strikt in het vasthouden van de methode. 303 zit daar tussenin, het zegt niet alleen wát er moet gebeuren, maar ook hóe.
Afsluiting
De 303 status code is misschien minder bekend dan 301 of 302, maar in veel gevallen de technisch juiste keuze. Hij maakt webverkeer betrouwbaarder, voorkomt dubbele acties, en zorgt ervoor dat je controle houdt over de flow van je applicatie.
Als je ooit een formulier hebt gebouwd waarbij gebruikers per ongeluk op ‘vernieuwen’ klikken en het formulier opnieuw wordt verstuurd, dan weet je waarom 303 bestaat.
Gebruik ’m bewust, en je bespaart jezelf en je gebruikers een hoop verwarring.
