Je wilt je WordPress-content in een andere applicatie gebruiken, een koppeling bouwen met een extern systeem, of je las de term in documentatie en vraagt je af wat er op jouw site eigenlijk allemaal “open” staat. In alle drie de gevallen kom je uit bij de REST API: de ingebouwde voorziening waarmee WordPress zijn content en functies beschikbaar stelt aan andere software. Elke moderne WordPress-site heeft hem aan boord en gebruikt hem zelfs intern, ook als jij er nooit bewust iets mee doet. In dit artikel maken we de API begrijpelijk: wat het is, hoe je ermee praat, hoe de toegangsrechten zitten en waar hij in de praktijk voor wordt ingezet.
Wat een REST API eigenlijk is
Een API (application programming interface) is een afgesproken manier waarop software met andere software praat, zonder tussenkomst van een mens met een browser. REST is de meest gebruikte stijl daarvoor: je vraagt gegevens op via gewone webadressen en krijgt ze terug als JSON, een gestructureerd tekstformaat dat elke programmeertaal kan lezen. Concreet: waar jij als bezoeker jouwdomein.nl/blog opent en een opgemaakte pagina ziet, kan een applicatie jouwdomein.nl/wp-json/wp/v2/posts opvragen en krijgt hij dezelfde blogberichten als kale data terug: titel, inhoud, datum, auteur, netjes gestructureerd. Probeer dat adres gerust eens op je eigen site; wat je dan ziet is de REST API in werking.
Endpoints: de adressen van je data
Elk soort gegeven heeft een eigen adres binnen de API, een endpoint. Alles begint bij /wp-json/, en daarachter volgen de routes: /wp/v2/posts voor berichten, /wp/v2/pages voor pagina’s, /wp/v2/media voor bestanden, /wp/v2/users voor gebruikers, enzovoort. Met parameters filter en sorteer je, bijvoorbeeld ?per_page=5&orderby=date voor de vijf nieuwste berichten. Plugins kunnen eigen endpoints toevoegen: WooCommerce levert bijvoorbeeld een complete API voor producten en bestellingen. Voor developers is verder relevant dat je met eigen code ook zelf endpoints kunt registreren, waarmee WordPress als contentbron voor vrijwel elke toepassing kan dienen.
Lezen mag, schrijven vereist een sleutel: authenticatie en rechten
Hier zit het deel dat elke site-eigenaar zou moeten kennen, ook wie nooit een regel code schrijft. De API volgt dezelfde rechtenstructuur als je site zelf. Alles wat publiek op je site staat, is ook via de API publiek leesbaar: je gepubliceerde berichten en pagina’s zijn zonder inloggen op te vragen. Dat is geen lek maar het ontwerp; het is dezelfde informatie die elke bezoeker al kan zien. Alles wat verder gaat (content aanmaken, wijzigen, verwijderen, conceptteksten lezen) vereist authenticatie: de aanvrager moet bewijzen wie hij is, en krijgt dan precies de rechten van de bijbehorende gebruikersrol.
De standaardmanier daarvoor zijn applicatiewachtwoorden: aparte wachtwoorden per koppeling, die je aanmaakt onder Gebruikers, dan je profiel, onderdeel Applicatiewachtwoorden. Het grote voordeel boven je gewone wachtwoord: je geeft elke koppeling een eigen sleutel, ziet welke er bestaan en trekt er één in zonder de rest te raken. Twee gewoontes maken dit veilig. Maak voor koppelingen een aparte gebruiker aan met niet méér rechten dan de koppeling nodig heeft: een dienst die alleen berichten plaatst, krijgt een auteursrol, geen beheerdersrol. En loop je applicatiewachtwoorden periodiek na, net als je gebruikerslijst; een vergeten koppeling met beheerrechten is precies het soort stille achterdeur dat je wilt voorkomen. Dit nalopen hoort bij het normale beheer van je site, zoals beschreven in onze complete gids over WordPress-beheer.
Waar de API in de praktijk voor wordt gebruikt
De toepassingen vallen grofweg in drie groepen. Koppelingen: externe systemen die met je site praten, zoals een boekhoudpakket dat bestellingen ophaalt, een nieuwsbriefdienst die nieuwe berichten uitleest, of automatiseringsplatformen zoals Zapier en Make die WordPress verbinden met honderden andere diensten. Automatisering: eigen scripts die bijvoorbeeld content publiceren vanuit een spreadsheet, of dagelijks gegevens synchroniseren tussen systemen. En headless sites: opzetten waarbij een losse frontend alle content via de API ophaalt en WordPress puur als beheeromgeving dient. Ook goed om te weten: de blokbewerker in je eigen dashboard gebruikt de API intern voor vrijwel alles. Werkt de bewerker ineens niet meer terwijl de rest van de site het doet, dan is een geblokkeerde API (vaak door een beveiligingsplugin of firewall-regel) een klassieke oorzaak.
Moet je de API uitschakelen?
De vraag komt geregeld voorbij in beveiligingsadviezen, dus een eerlijk antwoord: nee, volledig uitschakelen is af te raden, want je dashboard en veel plugins hebben de API zelf nodig. Wat wél zinnig kan zijn: het endpoint /wp/v2/users beperken voor niet-ingelogde aanvragers, omdat dat gebruikersnamen prijsgeeft die bij inlogaanvallen van pas komen. De meeste beveiligingsplugins hebben daar een nette optie voor. Verder geldt: de API is zo veilig als je gebruikers en wachtwoorden, dus daar zit je echte beveiligingswerk.
Bij Surver: ga je experimenteren met API-koppelingen of eigen scripts, doe dat dan niet rechtstreeks op je live site maar op een kopie, en zorg dat er een recent herstelpunt is. Bij onze managed pakketten staan de dagelijkse automatische back-ups daarvoor klaar, en hoe je zelf een testkopie opzet lees je in onze complete gids over WordPress back-ups en migratie. Onze support denkt zeven dagen per week mee als een koppeling zich vreemd gedraagt.
Van begrip naar gebruik
Voor de meeste site-eigenaren is de winst van dit artikel vooral begrip: je weet nu wat er via /wp-json open staat, hoe je koppelingen veilig van rechten voorziet en waarom die ene automatisering werkt zoals hij werkt. Wil je zelf gaan bouwen, dan is de officiële REST API-documentatie van WordPress de volgende stap. En bouw je gewoon een goede site zonder koppelingen, dan is er niets aan de hand: de API doet stilletjes zijn werk op de achtergrond, terwijl jij verder kunt met de zichtbare kant via onze startgids voor het maken van een website met WordPress.
