Niels de Blaauw – REST API HACKING – 6 JAAR LATER
Mag ik een warm applaus voor Nieuws de Blauw? Dankjewel, superleuk dat jullie gekomen zijn. Vrijdag ochtend en tien uur. Ik had verwacht dat er wat meer rode oogjes, wat katen zouden zijn, maar volgens mij valt het mee. Maar ten voorbereiding heb ik wel de presentatie in Dark Mode. Dat scherm is echt een 40 watt lamp in je gezicht. Dus de rest van de presentatie is donkere tweede deentje. Er komen straks wat code voorbeelden langs. Hier zo kun je gewoon de slides downloaden, die staan een maandag op. Express niet voor het weekend, wat ga je gewoon lekker weekend houden, maar als je dingen na wilt kijken of je iets gezien hebt, waarvan je nog even denk van, even teruglezen, hier staan ze een maandag op. Als je foto maakt kan dat natuurlijk ook. Ben ik achterin goed te verstaan ook? Bredelijk. Bredelijk, oké, iets harder nog. Iedereen deze URL op die het wil hebben. Sets jaar geleden was voor mij de eerste wordcam die ik bezocht. Ik was zes jaar geleden net in dienst bij Level Level. Ik werd uitgenomen voor een tripje naar WorldCamp Europe in Sevilla. En ik zat midden in een verhuizing. Ik was net bij Level Level begonnen en daar heb ik overslagen. Twee maanden later was WorldCamp Nederland. Daar ben ik naar toe gaan. En daar super veel leuke mensen ontmoet. Ik kende op dat moment nog helemaal niemand binnen de WordPress community. Maar ik zat als voorbereiding op de prestatie wat foto's uit 2016 terug te kijken. En nu ken ik in principe heel veel mensen die nog op die foto staan. Het is heel grappig hoe er in die zes jaar hoeveel mensen er zijn blijven hangen in die community. Sets jaar geleden woonde ik een prestatie bij over de WordPress API. En die heette de WordPress API, hacking the WordPress West API. En dat was belangrijk omdat op dat moment de trend rondom de WordPress West API er zo uit zag. Dat best wel booming op elk evenement op dat moment werd overgesproken. Wat kan je ermee? Waarom is het belangrijk? En even kijken, dit praatje van Jeroen van Dijk. Dat was degene die mij echt triggerde om ermee aan het slag te gaan. Op WorldCamp Nederland zes jaar geleden.  En nu dacht ik, oké, maar wat is er in de afgelopen zes jaar dan precies veranderd in de WordPress API? Zijn we vooruit gegaan? Wat voor ontwikkelingen zijn er geweest? Kunnen de dingen beter? Hoe gebruiken we het eigenlijk? En wat voor trucjes heb je nog steeds nodig waar hij op dat moment al van zei, hier moet je rekening mee houden, hier moet je omheen hacken. Eerst even terugkijken naar wat is de WordPress API? Wie is er gisteren naar het praatje van Johan geweest over de WordPress API? Best veel mensen hebben ook een beetje de historie van de rest-API in zijn algemeenheid meegekregen en waar het verdient. Maar voor iedereen die daar nog niet direct ervaring mee heeft, het is een gestandaliseerde manier om data in en uit WordPress te krijgen, of in ons geval WordPress te krijgen, waardoor je ineens platform onafhankelijk bent. Dus je kunt een externe automatiseringstoel aan WordPress koppelen, je kunt de handscanner van de Albert Heijn kun je aan WordPress koppelen, je kunt je Smartwatch en WordPress koppelen, je kunt van allerlei soorten devices kun je ineens met WordPress laten werken. En daar gaat WordPress van een CMS naar meer een soort van platform om content te beheerden. Ik ga dus niet verder praten over hoe de WordPress API ten stand is gekomen, maar meer over wat is er nu in de afgelopen zes jaar gebeurd sinds dit praatje. Allereerste, op het moment dat het praatje werd gegeven eind 2016, was de rest API nog geen onderdeel van Core. Het was een plug-in, op dezelfde manier dat Kuttenberg als plug-in werd ontwikkeld, en in WordPress 4.7 werd de rest API pas onderdeel van Core. Dus op het moment dat het praatje werd gegeven, was het nog een plug-in installeerd, was het nog heel erg niche van wie daar een gebruik van was. Op het moment dat het in Core werd gemurkt, nou je ziet hier zo, post comments, terms, users, meta en settings, maar er missen ook nog een hele hoop dingen op dat moment. Geen toegang tot menu's, geen toegang tot teams en plug-ins, geen search via de rest API, geen widgets. Dat was de start van de rest API binnen Core. Vervolgens, ik moet ook twee keer klikken, dat is irritant, kwam Kuttenberg in WordPress 5.0, de block-editor.  De block-editor is in die afgelopen zes jaar echt een beetje een drijffeer geweest voor ontwikkeling van de rest API. Na 4.7 naar het gemurkt, stond het hele even een beetje stil, maar de block-editor heeft dat weer echt een beetje een boost gegeven. Ze hebben ook een beetje een gedeelde afhankelijkheid. De block-editor was niet mogelijk geweest zonder een rest API, en andersom is de rest API, heeft heel veel van zo'n ontwikkeling te danken aan het feit dat Kuttenberg erop werkt. Door de toevoeging van Kuttenberg zijn bijvoorbeeld de search- en content-endpoints verder aangescherpt en ook nu met full-site editing, merk je dat er ineens een hele hoop onderdelen, zoals widgets en block-patterns en dat soort dingen, aan die WordPress rest-API wordt toegevoegd. Maar je ziet wel dat de belangrijkste drijffeer voor ontwikkelingen aan de rest API is op dit moment de block-editor. Wat er ook gebeurt is in die afgelopen 6 jaar, is dat er plugins zijn geweest die mee zijn gaan doen met de rest API, die hun functionaliteit via de rest API aan het blootstijden zijn. Bijvoorbeeld Advanced Custom Fields, die sinds, even kijken, het staat hier zo, 2021 november 2021 het mogelijk maakt om bij de Custom Fields aan te geven dat ze ook via de rest API opgevraagd mogen worden. Contact Form 7 sinds maart 2017, WooCommer sinds april 2017, Gravity Forms maakt het mogelijk om formulieren, insturen, formuleren te renderen via de rest API, de Joost sinds april 2020, dus er komen best wel veel plugins die wij gewend zijn uit het ecosysteem van WordPress en die ook de kracht zijn van het WordPress-ecosysteem, die gaan ook met de rest API werken. Wat je wel ziet, is dat er nog heel weinig plugins zijn die echt gebouwd worden met een API-first mindset, waarbij de basis vormt voor hoe zij met WordPress werken. Het gaat veel meer nog om traditionele plugins die vervolgens een rest API de bovenop krijgen. Zeker klikken. De toeling ontwikkelt zich. Dat is ook een belangrijk onderdeel van het ecosysteem.  Inmiddels zijn er veel meer tools beschikbaar over het werken en de debuggen van de rest API, waar je voorheen in het praatje van Jeroen zes jaar geleden nog om dingen heen moest werken om de rest API te verbergen of dingen uit te zetten in de rest API, kun je nu gewoon een plugin downloaden en aanklik van ik wil dit wel zien, ik wil deze mee te zien, ik wil die post-type wil ik niet terugzien in de rest API. Dus het aanzettenuitzet van content wordt makkelijker en ook het idee van WordPress als soort low-code-platform wordt daarmee aangesterkt. Verder toeling zoals de rest API-log, super in het zand, is een debugging tool die je kunt aanzetten in je WordPress-installatie en daarbij kun je zien wat voor requesten naar de WordPress-API wordt gestuurd. En dan kun je precies zien wat voor method er is gebruikt, naar wat verpatte het is geweest, wat de response-time is geweest, hoeveel content er is teruggestuurd, onder wat voor gebruik dat is gebeurd. Super nuttige tool om te hebben op het moment dat je wil gaan debugging en kijken waar komen de interacties met die rest-API vandaan. Want wat belangrijk is bij de rest-API is dat jij niet controle hebt over wie de gebruiken zijn van de rest-API. Misschien is er een externe partij die tickets verkoopt voor jouw site en dan ordersinschiet bij jouw WooComers-installatie. Hoe weet je dan hoe ze dat doet en wat voor die quest zij sturen en of dat goed gaat of niet. Rest-API-log. Ja, dat zes keer klikken volgens mij inmiddels. Maar dat komt goed, dan kan ik. Ik kan heel goed klikken. Nog even een detailview. Je kunt precies zien waar het naartoe is gaan maar ook de request headers. En dit maakt het ook heel makkelijk om lokaal bijvoorbeeld met curl of met postman deze request na te boodsen. Van oké, wat is er dan precies naartoe gegaan op het moment dat het niet lukt? Kun je kijken van oké, hoe format ik weer dan dat het wel lukt? Of is misschien de authenticatie verkeerd geweest? Waar ligt het dan aan dat het mislukt is? Dit is een swagger interface, plug-in gemaakt voor de WordPress OpenAPI-specificatie.  En wat dit doet is, die zet het schema van jouw site om naar een OpenAPI-specificatie en deze tool vervolgens maakt dan mogelijk om via een GUI interlog request te doen. Je neemt je wat meer aan de hand dat je door een JSON-bestand moet gaan zoeken in wat er allemaal mogelijk is op deze site. Ook superinteressant om op een hele eenvoudige, laagdrempige documentatie te delen met externe gebruikers. Dit is query monitor. Sinds mei 2021 ondersteunen die debugging output voor restAPI-responses. Dus op het moment dat je op je website query monitor aan hebt staan en je doet een request, dan zie je vervolgens in de response daarvan zie je wat voor database queries zijn er gedaan, hoe lang hebben al die database queries erover gedaan, zijn er dubbele database queries, zijn er errors geweest op de site. Dus je kunt hier zo precies zien dat in deze pageload 15 database queries zijn gedaan waarvan dit er één is en die duurde een duizendste van een seconde en gaf 317 resultaten terug. Supernutig op het moment dat je performance problemen hebt om op deze manier te kunnen zien waar ligt dat dan precies aan. We hebben gisteren natuurlijk ook bij Praatje van Floris gezien dat je dan vervolgens verschillende mogelijkheden hebt om te kijken moet we wel de restAPI gebruiken moet deze plugin wel ingehaakt zijn op het moment dat we de restAPI call afhandelen. Dus als je die talk gisteren niet hebt gezien kijk die dan even terug op Purpose TV want als je hier zo dingen in ziet die niet kunnen dat is de manier om het op te lossen. Krik! Ja, ja wees. Even good op het scherm. Eén van de dingen die 6 jaar geleden nog moest was lag een hele grote focus op het aanmaken van je eigen endpoints. En dat was voornamelijk om te zorgen dat er wat custom data op endpoints beschikbaar waren. Er was op dat moment dat de presentatie werd gegeven en was er al een register post meta waarin je show in rest kon aangeven maar die kon alleen maar simpele datetypen aangeven. Dus alleen maar strings, ins, booleans dat soort dingen. Sinds WordPress heb ik hier niets aan. Volgens mij 5.5, 5.6 kun je ook complexe datetypen meegeven in de rest de API. Dat is op deze manier te registreren.  Dus we doen een register post meta we geven aan dat er een metafeld projects is en dat die bestaat uit een array. Vervolgens in de show in rest kunnen we een heel schema definieren over dit bestaat uit een object en daar zitten twee strings in. Vervolgens is de output wat we je rest zien. Dus het is een stuk makkelijker geworden om voor jouw plug in op het moment dat je meta dat registreert om eigenlijk binnen een paar regels code de juiste formatting te krijgen om die data bloot te stellen via de rest API. Wat er ook nieuw is sinds die afgelopen 6 jaar en hiermee gaan we wat dieper op een authenticatie vraag stukken zijn de application passwords. En de application passwords zijn de manier om te zorgen dat jij vanuit een externe site of vanuit de first party site data kan opvragen die beveiligd zijn met gebruikers of plugins of edit commanders kan sturen naar de rest API server. Dus vanaf het begin is eigenlijk de manier geweest om te authenticeerden met de rest API om dat met een cookie te doen die standaard door WordPress wordt gezet waarmee wordt aangeven dat jij een ingelocht gebruik bent en dan vervolgens een nonce mee te sturen om te zorgen dat er geen externe website zijn die ons jouw aanpassingen kunnen doen in de WordPress API. 