El trabajo de los autores sería mucho más complicado si no existieran sistemas de gestión de contenido. Con un CMS el contenido se edita en el backend y se muestra en el frontend, en lugar de hacerlo directamente en el código de la página web. Esto funciona de manera óptima si se gestiona una única página, pero los redactores y los directores de contenido suelen administrar varias páginas y aplicaciones a la vez. Para ello se necesita más de un CMS, lo que significa que los contenidos deben trasladarse de uno a otro o, por otro lado, recurrir a un headless CMS que permita la edición en medios diferentes.
Un headless CMS es tanto una evolución como una reducción a partir de un CMS clásico: algunos componentes integrales del sistema son retirados para hacerlo compatible con las tareas más diversas. Esto es posible porque en un headless CMS tanto el frontend como el backend no están vinculados de forma monolítica entre sí.
En un CMS clásico el contenido se introduce en el backend a través de una interfaz y se organiza en bases de datos, normalmente MySQL. Desde aquí el sistema lo vincula con los temas (hojas de estilo) y muestra la página web en el frontend. Los sistemas de gestión de contenido como WordPress, Drupal o TYPO3 están diseñados para simplificar el trabajo diario del redactor. En la interfaz de administración se pueden crear y editar textos sin tener conocimientos sobre diseño web o programación.
Un ejemplo clásico de aplicación de un CMS es el blog. Los bloggers suelen publicar contenido (textos, fotos, vídeos) muy a menudo integrándolos desde la sección de administración del backend con ayuda de editores HTML o WYSIWYG. Una vez hecho esto, fijan la fecha de publicación. Esto permite que puedan concentrarse en escribir sin tener que ocuparse de la programación. Otra ventaja a este respecto es que varios usuarios pueden adquirir diferentes roles y permisos para trabajar en el backend, lo que hace que los CMS también actúen como sistemas de redacción. Los lectores del blog no perciben nada de todos estos procesos, porque solo tienen acceso al frontend, que es donde leen el contenido publicado.
Para que resulte sencillo utilizar estos sistemas, se recurre a una relación monolítica entre frontend y backend. En la interfaz de administración de WordPress, por ejemplo, el aspecto de la página se puede modificar con ayuda del generador de plantillas aun sin contar con experiencia en diseño web. Esto también significa que la creación de contenido está ligada a las normas del sistema, lo que se aplica tanto al número de tareas como a la utilización del lenguaje de programación (en WordPress se emplea PHP). Para sortear estas limitaciones se puede recurrir a un headless CMS.
En un headless CMS la tarea de mostrar el contenido gestionado con un CMS en diferentes medios queda relegada a la página web (la vista). Al CMS se le quita el encabezado, por así decirlo (de ahí su nombre). En su lugar se integra una API (Application Programming Interface) a la que pueden acceder las páginas web y las aplicaciones, de forma que los diferentes medios regulan individualmente la presentación del contenido: el backend y el frontendestán desacoplados.
Una API REST (Representational State Transfer) es una interfaz no muy compleja pero sí muy flexible que emplea métodos de consulta definidos como HTTP PUT, GET, POST y DELETE para comunicarse, comandos por medio de los que un cliente puede acceder a los datos del servidor, solicitarlos o modificarlos. Por lo tanto, REST sigue fundamentalmente el estilo de arquitectura de la Web. Las API REST, también conocidas como “API RESTful”, se construyen en base a estos criterios:
Si se siguen estos principios estructurales, la comunicación entre servidor/API y los diferentes clientes tiene lugar sin problemas, de ahí que la arquitectura REST resulte perfecta para la API de un headless CMS.
en realidad REST es más una idea que una técnica. El informático Roy Fielding la presentó en el año 2000 como constructo de la World Wide Web en su tesis doctoral y por ello obtuvo un gran reconocimiento.
Esta separación resulta útil desde dos perspectivas. Desde el punto de vista del desarrollo del backend, existe el deseo de divulgar el contenido en más de una edición. En un headless CMS no importa la plataforma a través de la que se distribuyen los contenidos, pues la API REST solo proporciona los datos (en formato JSON), los cuales pueden leerse desde cualquier tipo de frontend independientemente de la tecnología con las que se programen.
También aparecen ventajas desde el punto de vista del desarrollo del frontend: al utilizar un headless CMS, los diseñadores web ya no están ligados a las condiciones del gestor de contenidos, de la misma forma que el lenguaje de programación tampoco está definido. Esto permite la creación de aplicaciones móviles en diversidad de plataformas. Únicamente han de recibirse y editarse los datos brutos, lo que ofrece un margen más ampliode maniobra en su presentación que con los CMS clásicos.
Otra de las ventajas es la capacidad de realizar solicitudes dinámicas. En los CMS clásicos la consulta de nuevos contenidos en una página web suele hacer que la página se cargue de nuevo. Por el contrario, la API REST entrega datos dinámicos que se pueden integrar en cualquier momento en la estructura de la página sin necesidad de volverlos a cargar.
De la separación entre el backend del headless CMS y el frontend individual surge una situación práctica: debido a las modificaciones constantes en las tendencias del diseño web, es útil hacer ajustes de vez en cuando en la propia página web. Si esto no está ligado a la base de datos y al gestor de contenidos, puede realizarse de manera independiente. Así, los redactores pueden seguir trabajando en el contenido mientras los diseñadores editan el frontend.
Resumiendo, las ventajas de un headless CMS son:
El mercado ya cuenta hoy en día con algunos sistemas headless de gestión de contenido, pero su número va en aumento. Los fabricantes que aparecen a continuación se diferencian principalmente en si ofrecen un paquete de pago o una versión open source, pero también proporcionan diferentes opciones de hosting.
Para decidirse por el headless CMS más adecuado se deben cuestionar las necesidades y los conocimientos particulares. Quien tenga un servidor propio y la capacidad de incorporar un CMS open source puede hacer uso de las versiones gratuitas de eZ Systems o Directus. Si no tienes los conocimientos para instalar y configurar el sistema, debes entonces recurrir a una versión de pago para poder beneficiarte de todaslas ventajas de este sistema de gestión de contenidos.
Un headless CMS no siempre es la decisión adecuada para cada situación: si solo se busca la forma de publicar contenido, con el cambio a una nueva arquitectura se complica la vida innecesariamente, pues esto da lugar normalmente a más trabajo para los servidores, de modo que aumenta el gasto. Lo que en cualquier caso es necesario es configurar elfrontend, algo que no tiene que hacerse en el caso de un CMS clásico, en el que el frontend se crea mediante un generador de plantillas.
Los autores pueden echar en falta asimismo una función que ofrece todo CMS tradicional: un headless CMS no lleva integrada la vista previa del contenido publicado, por lo que debido a que los componentes están completamente separados entre sí, el backend no sabe cómo debe presentarlos. Es aquí donde entran en juego los llamados decoupled CMS.
La característica “decoupled” también se aplica en principio a los headless CMS, puesto que backend y frontend ya no son una unidad. El decoupling progresivo, en cambio, define el método por el que, en lugar de suprimir el frontend, se conectan API: no se acorta nada, sino que se amplía. Es así como la edición del contenido sigue estando en manos del CMS. También es posible acoplar otros frontends gracias a un plugin que genera las interfaces.
De esta manera las ventajas de los CMS conocidos se mantienen: el contenido se presenta desde el motor interno, incluyendo también las plantillas de formato. Si quieres ofrecer tu contenido por medio de una aplicación, los datos pueden obtenerse de las API que se han integrado. Esta alternativa ampliada te ofrece las ventajas de los CMS clásicos y de los headless CMS.
Cada vez se habla más de los headless CMS, por lo que los proveedores de los CMS tradicionales están cambiando de perspectiva. WordPress, por ejemplo, ha integrado la API REST como componente integral a partir de la versión 4.7. En las versiones anteriores esta solo podía conectarse mediante un plugin, por lo que la extensión no lo convierte en un headless CMS, sino más bien en un decoupled CMS. Los usuarios que le dan valor al alcance y al generador de plantillas de esta solución pueden trabajar sin pérdidas funcionales. No obstante, quien quiera usar el CMS para gestionar los contenidos de una app puede sacarle partido a las interfaces. Drupal también puede transformarse en un híbrido, pues el hecho de que este CMS open source proporcione los servicios web RESTful a partir de la versión 8 plantea la posibilidad de distribuir contenidos en muchos frontends.
Cambiar de un sistema con el que se está familiarizado a un headless CMS depende principalmente del proyecto. Si solo quieres presentar tus contenidos en una página web como un blog, no es recomendable prescindir del frontend. Los headless CMS también plantean ventajas que sobrepasan el volumen de los posibles modelos de salida, lo que rara vez justifica el esfuerzo. La utilización de un decoupled CMS, no tiene, por su parte, un valor añadido: ¿para qué implementar una interfaz si solo se utiliza el frontend incorporado en el sistema?
La situación es distinta cuando se utillizan diferentes plataformas. Los headless CMS pueden ser una alternativa óptima si se quieren crear proyectos de gran envergadura, ya se trate de proyectos multicanal, de páginas web en PHP, Python o Ruby, o de apps para iOS o Android. Los creadores de contenido pueden seguir gestionándolos a través de la interfaz de manera habitual. En los headless CMS (y al usar decoupled CMS correctamente), los frontend developers profesionales son los que se ocupan de la presentación, pero también se puede recurrir a la API REST.
La remodelación (no se puede hablar de reducción de sistemas cuando se habla de desarrollo) de los sistemas de gestión de contenido es una reacción a las necesidades cambiantes de Internet. Las particularidades de los smartphones, del Internet de las Cosas o de las realidades virtuales hacen necesario hallar un nuevo concepto para crear y publicar contenido. Los headless CMS y los decoupled CMS solo son el principio. Por ello, incluso cuando actualmente es suficiente trabajar con un CMS tradicional, no hay que perder de vista las nuevas tendencias. En vista de la rápida evolución de los últimos años, es posible que los CMS clásicos ya no se ajusten a las costumbres y necesidades de muchos usuarios, como es el caso de las páginas web estáticas.
¿Quieres crear tu propia página web o un blog? Para ello, el mercado ofrece diferentes packs que pueden ser útiles. Sin embargo, suelen ser bastante extensos para varios proyectos. El generador de páginas web estáticas Jekyll, estrechamente conectado con la plataforma GitHub, demuestra que es posible crear páginas web sencillas con las funciones estrictamente necesarias y sin necesidad de utilizar...
¿Quieres tener total libertad para crear páginas web? Si bien es cierto que WordPress es el líder indiscutible en este campo, el programa presenta algunas desventajas: elevados tiempos de carga, mayor probabilidad de hackeos, plugins poco seguros, etc. Por eso, para quienes ya cuentan con algo de experiencia y buscan una solución flexible y sencilla de usar, ProcessWire puede ser la alternativa...
Los dos métodos HTTP más conocidos y usados en páginas web son sin duda GET y POST. ¿Qué método es mejor? Te hablamos de estos dos métodos y te explicamos cuál es el que más conveniente y cuándo en la programación web.
Ofrece un servicio fiable y de alto rendimiento a tus clientes con un pack hosting de IONOS.
Ver packs
