5.5API REST y WordPress headless (nociones)
Lo esencial en 30 segundos
- La API REST expone el contenido de WordPress en JSON: /wp-json/wp/v2/posts ya devuelve los artículos.
- El headless utiliza WordPress como back-end de contenido, con un front separado (React, Next.js, aplicación móvil).
- Ventajas: libertad del front y difusión multicanal; contrapartidas: complejidad, pérdida de la vista previa y de muchos plugins de front.
Minicaso hilado — ¿hay que pasar el taller a headless?
Un desarrollador propone a Hassan un sitio headless «más moderno». Samir examina la necesidad real: un sitio de presentación y una pequeña tienda, sin aplicación móvil ni multicanal. Concluye que el WordPress clásico sigue siendo más sencillo y menos costoso. Aun así, muestra la API REST a Hassan para ilustrar la posible apertura hacia una aplicación de visita guiada, sin comprometer la renovación.
Continuación del caso 5.4 — conocer las posibilidades sin sobrevender.
1. La API REST en la práctica
WordPress integra una API REST: una interfaz que expone los contenidos y ciertas acciones en JSON, un formato legible por otras aplicaciones. Al abrir /wp-json/wp/v2/posts en un sitio, ya se obtiene la lista de artículos. Es la misma tecnología que alimenta el editor de bloques y numerosas integraciones.
Esta API permite que una aplicación externa — sitio front, aplicación móvil, panel de control — lea o publique contenido. Samir puede utilizarla para conectar una herramienta, sin rehacer el sitio. Verifica qué endpoints son públicos y cuáles exigen autenticación.
2. Headless: promesa y contrapartidas
El WordPress headless separa el back-end de contenido del front que lo muestra. Se conserva WordPress para gestionar los artículos y los medios, y se muestra mediante React, Next.js o una aplicación móvil. Ventajas: libertad total del front, rendimiento posible y difusión del mismo contenido en varios canales.
Las contrapartidas son reales: hacen falta dos competencias (WordPress + front), gestionar la vista previa, los formularios, el SEO, la caché y los plugins que dependen del front. Para la mayoría de los sitios, el WordPress clásico sigue siendo más sencillo y más barato. El headless se justifica en proyectos con una verdadera necesidad multicanal o un equipo técnico.
🔎 Ejemplo concreto — Una aplicación de visita guiada (caso Samir)
Necesidad real: una app móvil para visitar el taller.
WordPress sigue siendo el back-end de contenido.
API REST: /wp-json/wp/v2/realisations.
Aplicación: lee las fichas en JSON.
Sitio de presentación clásico conservado para la web.
→ Sin rehacer todo el sitio en headless.Resultado: un uso específico de la API, sin una renovación costosa.
Lección: se elige la arquitectura según la necesidad.
Vocabulario de la sección
- API REST
- Interfaz que expone los contenidos y acciones de WordPress en JSON.
Ejemplo sencillo: /wp-json/wp/v2/posts.
Lo que no es: creer que está reservada a los desarrolladores.
Reflejo: API = puerta de entrada de los datos.
- JSON
- Formato de datos ligero, legible por las aplicaciones.
Ejemplo sencillo: la respuesta de la API enumera los artículos.
Lo que no es: confundir JSON y HTML.
Reflejo: JSON = datos estructurados.
- Headless
- Arquitectura en la que WordPress proporciona el contenido y un front separado lo muestra.
Ejemplo sencillo: un front React sobre la API de WordPress.
Lo que no es: creer que headless siempre es más eficaz.
Reflejo: headless = back y front separados.
- Endpoint
- Dirección precisa de la API que devuelve un recurso.
Ejemplo sencillo: el endpoint de las realizaciones.
Lo que no es: exponer datos sensibles sin control.
Reflejo: verificar derechos y visibilidad.
- Autenticación API
- Mecanismo que protege los endpoints no públicos.
Ejemplo sencillo: una clave de aplicación para publicar.
Lo que no es: dejar la escritura abierta a todos.
Reflejo: las acciones sensibles exigen autenticación.
En la práctica — Explorar la API sin rehacer el sitio
- Abra /wp-json/wp/v2/posts en un sitio de prueba y observe la respuesta JSON.
- Localice un endpoint útil y verifique si es público o está protegido.
- Anote qué debería gestionar un front separado: vista previa, formularios, SEO, caché.
- Compárelo con un sitio clásico y decida qué está realmente justificado.
Guion listo para decir — reencuadrar el headless (25 s)
«El headless es potente para una aplicación móvil o varios canales, pero duplica la complejidad y el coste. Para su sitio de presentación y su tienda, el WordPress clásico sigue siendo más sencillo. Podemos utilizar la API para un uso preciso sin reconstruirlo todo.»
Hablar de necesidad antes que de tecnología: es el papel del asesoramiento.
Modelo copiar-pegar — decisión headless
NECESIDAD MULTICANAL REAL: sí / no
APLICACIÓN MÓVIL PREVISTA: sí / no
EQUIPO DE FRONT DISPONIBLE: sí / no
VISTA PREVIA / FORMULARIOS / SEO POR REPENSAR: _______________
ENDPOINTS PÚBLICOS VERIFICADOS: sí / no
DECISIÓN: WordPress clásico / headless / API específicaSitio de presentación
WordPress clásico; API solo para una integración.
Aplicación móvil
API REST + front móvil, back-end WordPress.
Multicanal
Un contenido, varios fronts: web, app, terminales.
Equipo técnico
Headless con front React/Next.js y CI/CD.
✓ Buenas prácticas
- Partir de la necesidad antes de elegir la arquitectura.
- Verificar qué endpoints son públicos.
- Proteger la escritura con una autenticación.
✗ Errores frecuentes
- Elegir headless por moda.
- Dejar la API abierta sin control.
- Olvidar la vista previa, los formularios y el SEO en el front separado.
Puntos clave
- La API REST expone el contenido de WordPress en JSON.
- El headless separa el back-end de contenido del front.
- Ventajas de libertad, contrapartidas de complejidad.
- La seguridad de los endpoints es indispensable.
Reto 48 h — aplícalo mañana
Abra la API de un sitio de prueba, localice un endpoint público y uno protegido, y enumere qué debería gestionar un front headless. 25 minutos.
- Comprendo qué expone la API REST.
- Sé explicar el headless y sus contrapartidas.
- Verifico la seguridad de los endpoints.
Preguntas frecuentes
¿Es el headless el futuro de WordPress?
Es una vía adaptada a ciertos proyectos — mucho tráfico, front a medida, multicanal, equipo técnico —, no una necesidad general. Para la mayoría de los sitios, el WordPress clásico sigue siendo más sencillo, más barato y eficaz con la caché.
¿Hay que saber programar para hacer headless?
Sí, bastante más que para un WordPress clásico: el front separado exige competencias de desarrollador web. Esta sección es una iniciación a las nociones, para saber cuándo merece la pena, no un tutorial de implementación.
¿La API REST es accesible para todos?
Algunos endpoints de lectura son públicos y otros exigen autenticación. Las acciones de escritura deben estar protegidas. Hay que verificar la configuración y no exponer nunca datos sensibles.
¿Qué es el WordPress «headless»?