¿Has escuchado este término dando vueltas? Está bastante de moda. Está muy relacionado con The Big Conversation™ en la web en los últimos años. ¿Cómo vamos a manejar traer Our Stuff™ todos estos diferentes dispositivos/pantallas/entradas?
El diseño receptivo dice “dejemos que nuestro diseño y medios se adapten a la mayor variedad de pantallas posible”.
La mejora progresiva dice “hagamos que la funcionalidad de este sitio funcione pase lo que pase”.
Diseñar para la accesibilidad dice “asegurémonos de que todos puedan usar esto independientemente de sus capacidades como personas”.
Un CMS sin cabeza dice “no vinculemos nuestros datos a ninguna forma de hacer las cosas”.
Un CMS “normal” nos da tres cosas
- Una forma de almacenar datos.
- Una interfaz de usuario CRUD
- Formas de mostrar los datos.
Un CMS “sin cabeza” solo comparte los dos primeros
- Una forma de almacenar datos.
- Una interfaz de usuario CRUD
- Una API para los datos
La “cabeza” (¡que estamos cortando! ¡eww!) es la parte de visualización o “vista” de un CMS.
Gráfico TL;DR
Comparación de tecnología
Quizás en un CMS normal, la única forma de acceder a los datos almacenados son las funciones que proporciona. Me gusta:
<?php MyCoolCMS->get_post_data(12); ?>
<h1>
<?php echo post_title(); ?>
</h1>
<?php echo post_contents(); ?>Si desea acceder a esos datos, la única forma de acceder es utilizando las funciones que proporciona. Probablemente podría escribir una vista que genere como una API. O puede escribir consultas en el almacenamiento de datos para obtener lo que desea. Pero esas cosas no son “ciudadanos de primera clase” del CMS.
En un CMS sin encabezado, el acceso a esos datos sería un punto final de URL como:
https://api.our-stuff.com/posts?id=12Que escupiría:
[
{
id: 12,
title: "Post Title",
authorName: "Chris Coyier",
dateCreated: "2007-07-03 10:42:02",
postContent: "<p>A long time ago...</p>"
}
]O algo así.
La estructura de la URL y los parámetros de consulta y todo eso dependerá del CMS y, con toda probabilidad, será “RESTful”. No estoy calificado para dar consejos allí, pero es bastante fácil buscar en la web y leer, así como ver implementaciones de referencia.
Ni siquiera sabes cuál es la próxima COSA.
Tal vez sea un pequeño implante en tu muñeca que proyecta una pantalla en tu antebrazo. Es súper popular. Todo el mundo está recibiendo uno. La empresa que lo fabrica permite que la gente escriba aplicaciones para él, pero no tiene un navegador web. Sin embargo, tiene acceso a la red.
Así que ahora, si quisiera, podría usar cualquier sistema que hayan configurado para escribir una aplicación, usar el acceso a la red y transferir sus datos para que los use.
No tenía que saber que se avecinaba algo nuevo, sus datos ya están listos para viajar.
El hecho de que sea una API no significa que las vistas que la usan sean del lado del cliente
Oh, genial, más sitios que solo funcionan con JavaScript.
No. El código del lado del servidor puede leer y digerir datos de una API tan bien como el código del lado del cliente.
¿Se puede usar un CMS “normal” como un CMS “sin cabeza”?
Seguro.
Tenemos un tutorial sobre la API REST de WordPress que puede ser de su interés.
WordPress es ciertamente un CMS “regular” en el que absolutamente tiene el concepto de vistas, pero no es necesario que use esas vistas. Si quisiera digerir WordPress completamente a través de la API, eso es posible.
Escuche una conversación completa sobre esto.
Dave Rupert, Jeff Eaton, Matt Dennewitz y yo hablamos extensamente sobre esto en ShopTalk.
¿La gente realmente está haciendo esto?
Si. He visto algunas implementaciones y escuché la historia del uso generalizado en las principales publicaciones. Sin embargo, no estoy seguro de estar autorizado o calificado para explicarlos.
¿Alguno de vosotros lo está haciendo?