add_filter('rest_prepare_brand', function($response, $post, $request) {
$data = $response->get_data();
// Păstrăm doar ce ne interesează cu adevărat pe frontend
$clean_data = [
'id' => $post->ID,
'title' => $post->post_title,
'slug' => $post->post_name,
'logo' => get_field('brand_logo', $post->ID)['url'] ?? null,
'website' => get_field('brand_website', $post->ID) ?: null
];
$response->set_data($clean_data);
return $response;
}, 10, 3);Am lucrat recent la o străpungere de headless WooCommerce pentru un magazin de piese auto cu vreo 15.000 de produse. Clientul voia neapărat Next.js pe frontend pentru viteză, dar echipa lor de marketing știa doar WordPress. Toate bune și frumoase până când a trebuit să adăugăm un Custom Post Type pentru "Producători" (Brands) legat de produse prin ACF-uri și să le trimitem curat în API.
Dacă lași WordPress-ul să își facă de cap implicit, API-ul lui REST arată ca o groapă de gunoi. Primești zeci de câmpuri inutile gen ping_status, template sau author când tu ai nevoie doar de titlu, slug și o imagine de brand. La un catalog mare, payload-ul devine rapid o problemă de performanță și de lățime de bandă.
REST API: Cum scapi de mizeria din JSON
Cea mai rapidă metodă să expui un CPT în REST este să pui 'show_in_rest' => true când îl înregistrezi. Dar asta îți trântește tot obiectul standard de post.
Ca să curățăm răspunsul, am preferat să scriu un filter în functions.php care curăță tot ce pleacă spre frontend. Decât să las ACF-ul să își pună blocul gigant de meta direct în root, am mapat doar ID-urile și URL-urile de care aveam nevoie.
Am obținut un payload cu 65% mai mic pentru endpoint-ul de producători. Iată cum arată abordarea mea preferată pentru a curăța răspunsul REST fără a rescrie rute întregi în WP.
Alternativa GraphQL: Când merită și când devine un coșmar
Dacă folosești WPGraphQL împreună cu WPGraphQL ACF, lucrurile par magice la început. Scrii interogarea în Next.js, ceri exact ce vrei și gata.
Dar am dat de un mare trade-off. Pe proiectul ăsta mare, cu zeci de câmpuri flexibile (Flexible Content), schema de GraphQL a devenit atât de complexă încât WP-ul crăpa din cauza lipsei de memorie la build-time. WPGraphQL are prostul obicei să mănânce resurse pe pâine când mapează relații complexe între CPT-uri și taxonomii de WooCommerce. Am avut cazuri în care build-ul în Next.js crăpa după 10 minute pentru că serverul de WP (o mașină cu 8GB RAM) rămânea fără memorie încercând să rezolve nodurile de GraphQL.
Dacă ai un site simplu de prezentare, GraphQL e aur curat. Dacă ai WooCommerce cu mii de variații și relații strânse între produse și CPT-uri, un REST API customizat și bine cache-uit (de exemplu, cu Redis) bate GraphQL-ul la orice oră din zi și din noapte ca stabilitate.
Concluzia mea după câteva proiecte headless
Nu folosiți pluginuri terțe care promit "REST clean-up" din interfață. Adaugă doar un alt strat de cod pe care nu îl controlezi și care adaugă query-uri inutile în baza de date. Scrieți acele câteva linii de PHP pentru a formata răspunsul exact așa cum îl vrea frontend-ul.
Voi cum procedați când aveți de-a face cu headless WP? Mergeți pe GraphQL pentru flexibilitate sau rămâneți la REST-ul clasic, dar curățat manual?