Hemos construido contra once APIs de CMS: qué deja hacer cada una a una IA
Hemos escrito adaptadores para 11 gestores de contenido y hemos manejado la API oficial de cada uno. En corto: todos se pueden leer, crear, editar y publicar, y las diferencias que importan están todas en los bordes —campos de SEO, menús, programación y redirecciones—. 6 de 11 pueden escribir datos de SEO. 3 llegan a un menú. 1 puede gestionar una redirección. La tabla entera está abajo, impresa desde los adaptadores en lugar de escrita a mano, que es la única forma de que una tabla así siga siendo cierta más de una semana.
·
Esta es la entrada que nos habría gustado tener antes de empezar. La documentación de cada plataforma describe una API capaz; ninguna dice con claridad qué deja fuera, y algunas describen cosas que no funcionan como da a entender la página. Lo que sigue es lo que encontramos construyendo contra cada una.
La tabla
14 trabajos en el lateral, 11 plataformas arriba. Cada plataforma enlaza con su propia página, donde esta misma información está desglosada y donde se anota el estado de verificación de cada fila.
| Lo que puedes pedir | WordPress | Joomla | Drupal | Craft CMS | Concrete CMS | Ghost | Webflow | Wix | Contentful | Strapi | Sanity |
|---|---|---|---|---|---|---|---|---|---|---|---|
| Leer el contenido | Sí | Sí | Sí | Sí | Sí | Sí | Sí | Sí | Sí | Sí | Sí |
| Crear contenido | Sí | Sí | Sí | Sí | Sí | Sí | Sí | Sí | Sí | Sí | Sí |
| Editar contenido | Sí | Sí | Sí | Sí | Sí | Sí | Sí | Sí | Sí | Sí | Sí |
| Publicar contenido | Sí | Sí | Sí | Sí | Sí | Sí | Sí | Sí | Sí | Sí | Sí |
| Programar publicaciones | Sí | Sí | No | Sí | No | Sí | No | Sí | Sí | No | No |
| Gestionar imágenes y archivos | Sí | Sí | Sí | Sí | Sí | Sí | Sí | Sí | Sí | Sí | Sí |
| Gestionar categorías y etiquetas | Sí | Sí | Sí | Sí | No | Sí | Sí | Sí | Sí | No | No |
| Editar la información SEO | Sí | Sí | No | No | No | Sí | Sí | Sí | No | No | Sí |
| Gestionar los menús | Sí | Sí | Sí | No | No | No | No | No | No | No | No |
| Tipos de contenido propios | Sí | No | Sí | Sí | Sí | No | Sí | Sí | Sí | Sí | Sí |
| Cambios en lote | No | No | No | No | No | No | No | No | No | No | No |
| Información del sitio | Sí | Sí | Sí | Sí | Sí | Sí | Sí | Sí | Sí | Sí | Sí |
| Gestionar redirecciones | No | No | No | No | No | No | No | Sí | No | No | No |
| Información de administración | Sí | Sí | Sí | No | No | Sí | Sí | Sí | Sí | No | Sí |
Esta tabla se genera a partir de los adaptadores al cargar la página, no está escrita a mano. Una casilla verde significa que el software intentará ese trabajo en esa plataforma; una gris significa que se niega antes de intentarlo, porque la plataforma no ofrece ninguna forma admitida de hacerlo. El trabajo por lotes es la única fila vacía en todas las plataformas: ningún adaptador lo reclama todavía, y la página de automatización lo dice también.
Cómo leerla: una casilla verde significa que nuestro software intentará ese trabajo en esa plataforma por su API oficial y admitida. Una gris significa que se niega antes de intentarlo, porque la plataforma no ofrece ninguna forma admitida de hacerlo. El gris nunca es un juicio sobre la plataforma: Webflow no tiene API de menús porque los menús viven en su editor de diseño, lo cual es una decisión razonable de Webflow y para nosotros simplemente un hecho con el que trabajar.
Cinco patrones en la tabla
Si miras la rejilla entera de golpe, aparecen siempre las mismas cinco cosas, te importen las plataformas que te importen.
- Leer y escribir están resueltos en todas partes. Las 11 listan contenido, leen uno entero, crean algo nuevo, lo cambian y lo publican. Si lo que quieres es un asistente que redacte y edite, la plataforma casi da igual.
- Los datos de SEO son la gran frontera. 6 de 11 exponen campos de SEO: WordPress, Joomla, Ghost, Webflow, Wix y Sanity. En las demás no hay dónde escribir; no es un permiso que nos falte, es que el campo no está en la API.
- Los menús no son casi de nadie. 3 plataformas llegan a la navegación: WordPress, Joomla y Drupal. En el resto, un menú es parte del diseño o una función de un plugin que guarda las cosas a su manera.
- La programación separa lo alojado de lo autogestionado, pero no como uno esperaría. 6 pueden poner una fecha futura de publicación: WordPress, Joomla, Craft CMS, Ghost, Wix y Contentful. Algunas de las plataformas más modernas de la lista no pueden, porque tratan la publicación futura como una función aparte y no como un campo de una página.
- Las redirecciones están casi en blanco. 1 de 11: Wix. En casi todas las plataformas una redirección es de un plugin, de una capa del alojamiento o de un archivo de configuración, y ninguna de esas tres es una API.
Cuatro cosas que no estaban en ninguna documentación
Estos son los hallazgos que costaron tiempo de verdad, y la razón de que esta entrada exista en lugar de un resumen de once páginas de características.
- Un token de Concrete CMS sin persona detrás es un visitante. Concrete ofrece credenciales de cliente —un identificador y un secreto, sin navegador, la opción obvia para un producto como el nuestro— y funciona: devuelve un token firmado y ese token lee la web sin problema. Después, cada escritura vuelve con un 403. El motivo es que Concrete ata los permisos a una *persona*, y un token de ese tipo no lleva ninguna, así que la petición se ejecuta como invitado. La vía admitida es aquella en la que el cliente aprueba la integración en su propia web, que además es mejor arreglo: ninguna contraseña llega hasta nosotros y puede retirarla él mismo.
- Wix no tiene ninguna API de páginas. No hay permiso de páginas en el catálogo de permisos del propio Wix ni API de estructura detrás, así que las páginas, los menús y la navegación de una web Wix no las alcanza nada fuera del editor de Wix. El blog, en cambio, se alcanza entero. Eso es un hecho lo bastante grande como para tener entrada propia, y la tiene.
- Webflow puede escribir el texto SEO de una página pero no la página. Un `PUT` sobre una página escribe su título, su slug y sus campos reales de SEO. El punto final para el texto visible rechaza de plano el idioma principal: la propia postura de Webflow es que el contenido de página en el idioma principal se cambia en el editor de diseño. Así que "las páginas de Webflow no se pueden editar" era medio cierto de una forma que importa: las palabras que lee un visitante, no; las que lee Google, sí.
- El texto alternativo casi nunca vive en la imagen. En Ghost, en Drupal y en Wix, la descripción de una foto pertenece al sitio donde se usa la foto y no al archivo, porque la misma fotografía puede significar cosas distintas en dos páginas. Tres plataformas llegaron a ese arreglo por su cuenta, lo que sugiere que es el correcto, y significa que "sube una imagen y escribe su texto alternativo" es un trabajo en unas plataformas y dos trabajos sin relación en otras.
REST, GraphQL y una que no es ninguna de las dos
Casi todas son APIs REST. Craft es GraphQL, y su API está en el núcleo de todas sus ediciones, incluida la más barata, aunque un esquema nuevo lee y no escribe: las casillas de escritura empiezan vacías, y un esquema con todo legible y nada escribible falla en silencio en lugar de protestar. Sanity es un lenguaje de consulta propio sobre un lago de contenido, donde los borradores son documentos aparte y no un estado de uno. Contentful y Sanity ni siquiera están en la dirección de tu web: tu web es lo que alguien construyó encima, y lo que se conecta es el almacén de contenido que hay detrás. Nada de eso cambia la forma de la tabla, que es el hallazgo útil: las diferencias que importan a quien le pide algo a un asistente no son las diferencias de las que se habla en la prensa técnica.
Qué significa esto si estás eligiendo
Si eliges plataforma *para* trabajar así, la tabla premia lo viejo y aburrido: WordPress y Joomla son las que más permiten, y lo permiten por interfaces que llevan años estables. Si ya tienes plataforma, la pregunta útil es más estrecha: de estos 14 trabajos, ¿cuáles dos o tres te importan de verdad? A quien quiere un asistente que redacte y ordene entradas de blog se le atiende bien casi en cualquier sitio. A quien quiere uno que cuide menús y redirecciones en una web grande lo atienden WordPress, Joomla y Drupal y nadie más, y eso conviene saberlo antes de comprar y no después.
Límite honesto: esta tabla dice lo que cada adaptador intentará, que no es lo mismo que lo que está demostrado. 9 de las 11 han tenido capacidades ejecutadas contra una instalación real y anotadas con su fecha; las demás están construidas a partir de la documentación y el código fuente de cada plataforma, y figuran como no probadas en sus propias páginas hasta que alguien las haya visto funcionar. Preferimos publicar la afirmación débil con exactitud que la fuerte con optimismo.
Lo que nos preguntan sobre esto
- ¿Qué plataforma permite más cosas?
- WordPress y Wix, con 12 de 14 cada una, por motivos opuestos: WordPress porque su API REST cubre casi todo, y Wix porque la única parte de una web Wix que se alcanza se alcanza a fondo. Joomla va detrás con 11.
- ¿Por qué está vacía la fila del trabajo por lotes?
- Porque todavía no la reclama ningún adaptador. En este producto un cambio por lotes es una edición normal repetida, con una vista previa y una aprobación delante, y hasta que eso no se ejecute plataforma por plataforma preferimos enseñar una fila vacía antes que una promesa.
- ¿Usáis algo no oficial para tapar los huecos?
- No. Ni automatización de navegador, ni rascado de páginas, ni puntos finales sin documentar. Si una plataforma no tiene forma admitida de hacer algo, la respuesta es que no se puede, y la casilla gris se queda gris.
- ¿Cada cuánto se revisa esta tabla?
- No se revisa cada cierto tiempo: se genera desde el software en funcionamiento cada vez que se carga esta página, así que está tan al día como el producto. La fecha de arriba es cuándo se repasó por última vez el texto que la rodea.