REST API errors: monitorare /wp-json/

La REST API è il backbone dei siti WordPress moderni (Gutenberg, app, headless). Quando genera errori, gli impatti sono spesso più gravi del semplice frontend rotto. Vediamo come monitorarla con WP Error Monitor.

Endpoint REST chiave

Default WP espone: /wp-json/wp/v2/posts, /pages, /users, /media. Plugin aggiungono: /wp-json/wc/v3/ (WooCommerce), /wp-json/yoast/v1/ (SEO), /wp-json/jwt-auth/v1/ (JWT). Ogni endpoint può avere errori 4xx (client) o 5xx (server). I 4xx sono spesso 'normali' (mancato auth), i 5xx sono bug da investigare.

Errori comuni REST API

1) 401 Unauthorized se nonce scaduto o auth header mancante, 2) 403 se l’utente non ha capability, 3) 404 endpoint non registrato, 5) 500 fatal in callback, 6) timeout su endpoint pesanti (e.g. WC products con grandi cataloghi). WP Error Monitor cattura tutti con tag 'context=rest_api' e include endpoint, parametri (sanitizzati), capability check fallito.

Snippet di monitoring

Aggiungi un filter wp_rest_response_data per misurare tempi per endpoint. WP Error Monitor lo fa automaticamente se WPEM_TRACK_REST=true: hai dashboard con tempi medi, p95, p99 per endpoint. Endpoint > 1s sono red flag, > 5s sicuramente bug.

Rate limiting per endpoint

REST API senza rate limit è esposta ad abuse: scraping prodotti, brute force user enumeration via /wp-json/wp/v2/users. Setup con plugin o custom: limita 60 req/min per IP per endpoint generico, 10 req/min per endpoint auth-related, 5 req/min per /users (sensibile). WP Error Monitor logga rate limit hits con tag 'rate_limited’ e mostra IP top in dashboard. Così' identifichi scrapers e attaccanti.

CORS e preflight su REST API

Per app frontend cross-origin (Vue/React su dominio separato), serve CORS configurato. WordPress REST API restituisce per default Access-Control-Allow-Origin: same-origin. Per cross-origin, hook rest_pre_serve_request e setta header. Preflight OPTIONS deve restituire 200, non 401. WP Error Monitor traccia preflight per tracking debugging cross-origin.

Caching REST responses

REST API endpoint con data pubblici e statici dovrebbero essere cached aggressivamente. Setup: rest_pre_serve_request hook setta Cache-Control header (es. 'public, max-age=300, s-maxage=900'). CDN (Cloudflare) rispetta header e cache 5min in browser, 15min in edge. Così' endpoint /wp-json/wp/v2/posts servito da edge senza colpire origin. Caveat: endpoint con auth o user-specific data NON cachable (max-age=0). Per cache invalidation, hook save_post che purga edge cache per relevant endpoints. WP Error Monitor traccia cache_hit_ratio per endpoint, identifying opportunities di tuning.

Versioning della REST API custom

Quando esponi REST API custom verso terze parti, versionalo da subito: /wp-json/miosito/v1/foo. Così' breaking change futuri sono in v2 senza rompere chi usa v1. Migration strategy: deprechi v1 con header 'Sunset' (RFC 8594), lascia 6-12 mesi per migrazione, poi rimuovi. WP Error Monitor traccia usage per versione: vedi quanti client usano ancora v1 deprecated e contatta direttamente. Senza versioning, ogni cambio rompe potenzialmente integrazioni invisibili, e nessuno è contento.

Roadmap evoluzione REST API

Roadmap evoluzione REST API per progetti WordPress moderni: 1) decommissioning gradual XML-RPC (sostituito da REST + Application Passwords), 2) versioning v1/v2 per API custom esposte, 3) rate limiting su endpoint sensibili, 4) caching aggressivo per endpoint pubblici, 5) GraphQL come opzionale per query complesse (plugin WPGraphQL), 6) monitoring uso per endpoint identificando quelli non utilizzati (candidati removal). WP Error Monitor traccia tutto: usage per endpoint, latency, error rate, version distribuzione tra client. Roadmap data-driven invece di intuizione.

REST API security audit

Audit security REST API trimestrale verifica: nessun'endpoint espone dati senza auth quando dovrebbe richiederla, rate limit attivi su endpoint sensibili, CORS configurato strict, version deprecate effettivamente rimosse. Audit standard 30 minuti, salva da exposure incident potenzialmente catastrofici.

Procedura passo-passo

1. Setta WPEM_TRACK_REST=true in wp-config.php.
2. Genera traffico tipico (app mobile, Gutenberg).
3. Apri WP Error Monitor > 'REST API Dashboard’.
4. Identifica top 10 endpoint per latenza e per errori.
5. Per endpoint lenti, ottimizza query SQL o aggiungi cache.
6. Per errori 5xx ricorrenti, apri dettaglio e fixa codice.
7. Configura alert su 5xx rate > 1% del traffico.
8. Monitora trend dopo deploy: regressioni saltano subito all’occhio.
9. Configura rate limit per endpoint REST sensibili.
10. Imposta CORS per applicazioni cross-origin specifiche.

Errori comuni e come risolverli

• REST API completamente bloccata: Plugin security troppo aggressivo (Wordfence con regola WAF): whitelistare endpoint.
• Nonce sempre invalid: Mismatch URL siteurl/home: verifica wp-config WP_HOME.
• Latenza alta solo su /wp-json/wc/: WooCommerce con grandi cataloghi: paginate response, abilita cache.
• Rate limit blocca utenti legittimi: Aumenta threshold o whitelist IP corporate.
• CORS preflight fail: OPTIONS bloccato da security plugin: aggiungi eccezione.

Domande frequenti

D: Posso disabilitare REST API per non-loggati?
R: Sì, con rest_authentication_errors filter: alza barrier alla maggior parte degli attacchi.

D: WP Error Monitor traccia anche REST custom?
R: Sì, tutti gli endpoint registrati via register_rest_route.

D: Posso monitorare anche payload size?
R: Sì, con WPEM_TRACK_REST_SIZE=true: utile per payload bloat.

D: Posso disabilitare REST API per non-loggati?
R: Sì, con rest_authentication_errors filter.

D: Endpoint REST più attaccati?
R: /wp-json/wp/v2/users (enumeration) e /wp-json/wc/v3/orders (data scraping).

Hai bisogno di aiuto?

Se vuoi affidare il monitoraggio WordPress al team di G Tech Group, scrivici tramite il modulo di contatto.