您是否听说过这个术语?它很流行。它与过去几年网络上的“大讨论™”密切相关。我们如何处理将“我们的东西™”带到所有这些不同的设备/屏幕/输入上。
响应式设计说“让我们让我们的设计和媒体适应尽可能多的屏幕变化”。
渐进增强说“让我们让这个网站的功能无论如何都能正常工作”。
为可访问性设计说“让我们确保每个人都能使用它,无论他们作为个人的能力如何”。
无头 CMS 说“让我们不要将我们的数据绑定到任何一种做事方式”。
“常规”CMS 为我们提供了三样东西
- 一种存储数据的方式
- 一个 CRUD UI
- 显示数据的方式
“无头”CMS 仅共享前两者
- 一种存储数据的方式
- 一个 CRUD UI
- 一个 API 用于访问数据
“头部”(我们正在砍掉!eww!)是 CMS 的显示或“视图”部分。
TL;DR 图表
技术比较
也许在常规 CMS 中,获取存储数据的唯一方式是它提供的函数。比如
<?php MyCoolCMS->get_post_data(12); ?>
<h1>
<?php echo post_title(); ?>
</h1>
<?php echo post_contents(); ?>
如果您想要访问该数据,唯一的入口是使用它提供的函数。您可能会编写一个类似 API 输出的视图。或者,您可以编写查询到数据存储中以获取所需内容。但这些东西不是 CMS 的“一等公民”。
在无头 CMS 中,访问该数据将是一个类似 URL 的端点,比如
https://api.our-stuff.com/posts?id=12
它将吐出
[
{
id: 12,
title: "Post Title",
authorName: "Chris Coyier",
dateCreated: "2007-07-03 10:42:02",
postContent: "<p>A long time ago...</p>"
}
]
或类似的东西。
URL 结构、查询参数等等都取决于 CMS,并且很可能是“RESTful”的。我没有资格提供这方面的建议,但它很容易在网络上搜索和阅读,以及查看参考实现。
你甚至不知道下一个“东西”是什么。
也许它是一个植入你手腕的小装置,可以在你的前臂上投射一个屏幕。它非常受欢迎。每个人都在买。制造它的公司允许人们为它编写应用程序,但它没有网络浏览器。不过它有网络访问权限。
因此,现在,如果您想使用他们设置的任何系统来编写应用程序,使用网络访问权限,并将您的数据传输到它以供使用。
您不必知道这个新事物即将出现,您的数据已经准备好传输。
仅仅因为它是 API,并不意味着使用它的视图是客户端的
哦,太好了,更多只用 JavaScript 才能运行的网站。
不。服务器端代码可以像客户端代码一样读取和消化来自 API 的数据。
您可以将“常规”CMS 用作“无头”CMS 吗?
当然。
我们有 一篇关于 WordPress REST API 的教程 可能会让您感兴趣。
WordPress 绝对是一个“常规”CMS,因为它绝对有视图的概念,但您并不需要使用这些视图。如果您想完全通过 API 消化 WordPress,那是可能的。
收听有关此主题的完整对话
Dave Rupert、Jeff Eaton、Matt Dennewitz 和我在 ShopTalk 上 详细讨论了这个问题。
人们真的在做这个吗?
是的。我已经看到了一些实现,并听说在主要出版物中广泛使用。但我不能确定是否有资格或被授权解释它们。
你们中有人在做这个吗?
是的,我非常赞成这种方法(以至于我自己的宠物项目网站正在以这种方式重建)。
长期以来,我一直在使用 CMS 来管理我的网站,这很好,但现在我已经到了不想受限于 CMS 中的内置视图组件,并想编写自己的 UI 层(可能在完全不同的堆栈中,例如 .net CMS 与 Node UI 层?)
随着 REST 微服务的日益普及,我不会感到惊讶,我们最终会看到更多 CMS 走向这条道路。
是的,我已经谈论过这个主题很长时间了(参见 https://community.laravel.net.cn/forum/05-13-2014-api-first-cms)。我知道 KeystoneJS 团队将他们的 CMS 用于各种应用程序,包括网络、移动和物联网。我还在研究是否可以公开不仅仅是 REST API,而是通过 WebSockets 公开实时 API。非常有趣的内容。
我发现了这个无头 CMS,看起来很酷(基于 5 分钟的研究) - https://www.contentful.com/。看起来您永远不会达到 API 调用的限制(对于免费计划),假设您正在缓存对服务的调用。
我在最近的一个副项目中使用了 Contentful 作为实验。我通过 Middleman 静态站点扩展连接了 API。因此,我能够获得静态站点的速度和灵活性的优势,同时获得常规 CMS 的 GUI。这就是 Vox 团队 Carrot Creative 使用的方式。
但是,我发现它的设置文档很差,而且需要很多反复试验。然后 Contentful 说我的 API 调用次数过多,所以我不得不关闭网站。付费版本每月 99 美元,因此希望价格能降下来,或者出现更便宜的竞争对手。
Carrot 在这里介绍了他们很酷的流程:https://www.contentful.com/blog/2015/04/28/webinar-contentful-roots-static-sites
已经存在更便宜的替代方案 http://alternativeto.net/software/contentful
这里有一个很好的示例 https://prismic.io/quickstart
我评估了所有我能找到的。
http://www.contentful.com
http://www.prismic.io
http://www.osmek.com
http://www.cloudcms.com
http://www.webhook.com(不太一样,但数据在 Firebase 中,所以可以用这种方式)
但最终还是在 Firebase 之上构建了一个小型 CMS SPA,因为它更适合我们预期的用例。
https://github.com/tivac/crucible/
它为 https://competitive.guildwars2.com 提供动力,总体来说很棒。
非常酷。干得好。加星了。=)
对于“普通”网站,我无法看到无头设置能带来任何价值,只会增加复杂性。如果你像 NPR 一样有多台服务器向分支机构提供内容,那么 REST API 会非常宝贵。或者如果你需要将内容提供给应用程序。当然,可以使用 REST。(也有其他技术。)
但对于我们其他人来说呢?网络已经够慢了,开发人员真的需要另一个抽象层吗?尤其是一个像 HTTP 那样冗长的层?如果你的视图层非常糟糕,以至于无法根据你的模型提供的內容获取你想要的内容,那么 REST 真的帮不了你。
我认为无头的真正标题是它让人们开始思考如何将内容与表示层分离。(这是最大的优势。用诺亚·斯托克斯的话说——我认为是 ShopTalk 的一期节目——他提到 CMS 实际上只是一个数据库接口。如今,随着多屏幕的出现,我们访问每个数据片段的方式越来越重要。
分离的设置让你思考如何实际访问这些数据。就像移动优先让我们开始思考如何为小屏幕准备内容一样,我们仍然可以制作一个很棒的桌面优先网站——前提是你关心你的网站如何在移动设备上显示。CMS 也是如此。
如果你的 CMS 没有提供将内容分解成块的工具,那就去掉 CMS。我喜欢 Craft 这样的工具,因为它们的工作原理就是这样。
像 WP 这样的 CMS 对此几乎没有概念。你可以得到一个标题,也许还有一个特色图片。但你有一个名为“正文”的文本墙,作者应该使用他们邪恶的 WYSIWYG 来格式化它。如果你想获取文章中的所有图片,你需要搜索并找到它们。如何找到使用相同图片的其他文章?比它应该做的更难。
WP 这里真的本末倒置了。REST API 很棒,但你需要更多内置的字段类型才能真正利用它。因此,我们依赖于像 Advanced Custom Fields 和 Pods 这样的工具来添加更多字段,帮助我们从这个内容块中提取内容。如果你曾经读过或观看过凯伦·麦格雷恩的文章,她对此非常直言不讳——blob 与 chunk。
应用程序的复杂性实际上取决于开发人员。我认为高级开发人员会发现完整的 CMS 更复杂(也许“繁琐”更合适),因为需要学习专有功能。然而,无头 CMS 很容易。只需安装它,然后构建你想要的应用程序。我想,如果一个开发人员不熟悉使用 CURL 库(如果是构建服务器端应用程序)或 AJAX(如果是构建 SPA 应用程序),那么完整的 CMS 更容易,因为他们可以选择一个主题,然后进行调整。
就性能而言,我认为这无关紧要。就像其他任何东西一样,它取决于开发人员的技能。2 个开发人员可以构建相同的 WordPress 网站,一个会很快,另一个会很慢,因为一个开发人员比另一个更高级。如果涉及缓存,则无需进行额外的 HTTP 请求。
我认为有大量用户正在构建这些 SPA 应用程序(看看 Angular 如何爆炸式增长)。你可以使用 DAAS(如 Firebase),但这实际上只是一个数据库……你仍然需要构建管理方面的东西(这是样板代码)。这些无头 CMS 实际上帮助填补了许多开发人员的空白。构建你的网站,不要担心冗余的样板代码。
@ Mike:我们在谈论应用程序还是网站?
我认为你低估了构建有能力的东西需要多少工作量,如果你认为无头很容易。
我来自客户服务领域,所以你的体验可能会有所不同,但听起来如果你认为一个好的后端 UI 只是样板代码,你还没有花太多时间和客户打交道。像纽约时报和 NPR 这样的机构已经花费了数年时间来确保这些系统满足他们的需求。
如果你的说法属实,为什么不是每个人都在使用完全定制的 CMS?为什么不是每个人都在构建自己的框架?因为最终,制作一个真正好的 CMS 是一个很难解决的问题。开发人员的技能只是一个变量。
客户不在乎你如何构建他们的网站,只在乎它是否满足需求。如果需求是向多个入口点提供内容,比如网站、移动应用程序等,那么也许分离的系统可能适合你。
Contently 和 prismic 是很棒的资源。但根据我的经验,对于我做过的多数基于内容的网站来说,分离的东西比它值得的麻烦要多一些。
一定有什么误解。没有人想构建一个定制的 CMS,因为这需要很长时间,而且它非常复杂。我不想构建一个定制的 CMS(永远!哈哈)(讽刺的是,我在日常工作中一直在构建一个 LMS……这已经花费了一年以上的时间)。
实际上,你可以放弃使用任何 CMS 的面向客户的视图层,本质上将其变为无头。这实际上是我采取过几次的方法,因为我当时没有意识到有真正的无头 CMS。随着 WordPress JSON API 的兴起,很明显其他人也喜欢 WP 可以提供的这种伪无头方法。
所以,开发时间……假设安装/配置一个完整的 CMS 和一个无头 CMS 所花费的时间相同,那么唯一的区别就是构建面向客户的网站所花费的时间,对吧?
CMS 不会帮助你,因为它不是网站构建器(比如 Squarespace)。无论如何,你都必须自定义编码。
此外,我并不是规定使用无头 CMS 因为它更好。它不是用来给你的客户留下深刻印象的武器,他们不知道 JS 和 PHP 之间的区别(或不在乎)。让 CMS 处理管理方面(内容创建、身份验证、资产管理等)。然后使用你最擅长的、喜欢编码的技术构建你的面向客户的应用程序。在我看来,它是一个让开发人员更容易的工具。
我喜欢!有时候人们只需要原始数据,正如蒂姆·伯纳斯-李爵士所说:现在需要原始数据!:-) http://www.wired.co.uk/news/archive/2012-11/09/raw-data
我认为,如果所有 CMS 都支持 API 路径作为其功能的一部分,那将非常有意义。为什么所有数据都要用 HTML 包装?未来可以轻松地基于数字助理,它们会为我们处理数据源。只要想想 Siri 和 Cortana,它们没有包装好的数据/内容。
我写了一篇关于这个主题的博文,是用丹麦语写的,但你可以使用谷歌翻译将其翻译成英文,如果你感兴趣的话 :-) https://www.linkedin.com/pulse/fremtidens-internet-er-api-baseret-sten-hougaard
/Sten
一个极其快速、高可用性、低维护网站的要素
一个云 CMS 来处理高可用性、跨多个区域的负载均衡等。
Angular 2 或其他同构 JS 框架
一个简单的静态文件服务器来提供你的 HTML 模板、样式表和脚本
然后只需通过与 CMS 的 API 交互来在客户端完成所有网站逻辑。视图组合、用户会话、分页、搜索等。
一旦浏览器下载了你的脚本文件,它就不需要再向你的服务器发送任何请求。好吧,也许还需要再发送几个请求来获取一些视图文件,但仅此而已。实际上,通过利用应用程序缓存,你可以让浏览器完全停止与你的服务器通信,即使在未来的请求中也是如此。它只需要与云 CMS 通信。
顺便说一下,我提到了使用同构 JS 框架,这样你就可以在服务器端渲染页面供爬虫抓取。也许对你的访客来说也是如此,但这并不是那么重要的要求。
我已经使用 interactivetools.com 的 CMS Builder 几年了,我认为它可以算作无头。它是一个完全可定制的 CMS 代码生成器和数据库。它们提供了一种从数据库中提取数据的机制,但没有视图。你可以创建自己的表(它们提供了一些常见的表),使用代码生成器获取基本代码来显示数据并根据你的意愿进行格式化。
它们有很多插件和一个强大的钩子系统来扩展功能。我正在使用一个简单的 DB 函数来提取数据,并使用 twig 来显示数据。
我已经开发了房地产网站、博物馆和美术馆网站,甚至电子商务网站。我可以在一到两周内创建一个功能齐全、可定制的网站。
ProcessWire (www.processwire.com) 已经做了很多年了。它的 API 很巧妙。
同上。 ProcessWire 比任何其他 CMS 都有更大的灵活性。它还有一个非常活跃的 用户社区,他们热爱他们的工作,并且做得非常出色。
https://www.processwire.com/
是的,ProcessWire 对编辑来说非常简单,但它在底层提供了强大的 API,可用于演示和管理。我已经两年没有使用过其他 CMS 了。
太棒了。还有一个。 https://cosmicjs.com/
嗨,Kelley!我是 Cosmic JS 的创建者。感谢分享 :) 如果你对 Cosmic JS 有任何疑问或需要帮助入门,请告诉我!我很乐意收到你的反馈。
如果我没弄错的话,http://pitchfork.com 是基于 WordPress REST API 和 Backbone 视图构建的。考虑到他们处理的流量量,这是一个相当不错的可扩展架构和美观设计的例子,而且没有牺牲性能。
总之我要说的是,Drupal 8。从一开始就是完全无头的,每个实体和视图都有一个端点,Dries 写了一篇关于将 Drupal(在核心内部)与 Angular 或 Ember 等框架捆绑在一起的非常棒的文章。
他们开始将这种与客户端框架集成更多的新概念称为“渐进式解耦”。我强烈建议你们中的任何人都去查阅一下并阅读一下。
我在 我的网站 上这样做。我运行的是 WordPress,并构建了一个插件来将我的帖子导出到服务器上的静态 JSON 文件(在保存/更新帖子时)。然后,我构建了一个 Node/Express/Angular 应用程序,它只获取正确的 JSON 文件(基于 URL 标识符)并将数据放入视图中。我本可以使用 WordPress REST API,这可能更复杂,但我认为在更改页面时只获取单个静态文件更快。它肯定可以改进,但到目前为止它对我来说效果很好。
在对话中添加另一个无头 CMS 服务
http://getdirectus.com
我们对无头、API 优先 CMS 的看法:http://getmesh.io
我完全同意这是构建 CMS 的新方法。我们正在从过时的已安装 CMS/数据库模型转向新的服务提供商模型(就像技术和非技术领域的其他一切一样)。
我是内容平台 Cosmic JS 的创建者,它不仅是开发人员自由快速地为网站和应用程序构建内容的绝佳平台,而且非技术内容编辑也能够直观地使用它。Cosmic JS 目前处于私人测试阶段,但我们有很多应用程序和网站正在生产环境中运行。注册并试用:https://cosmicjs.com。再次感谢 Chris 的精彩文章!
我非常支持这种方法。对于我们新公司的网站,我们被要求提供一个用户友好的后端,任何人都可以添加内容(理想情况下是 WordPress),但我们也希望前端成为我们技能的典范,所以我们想在它上面倾注所有精力。我真的不想在 WP 主题中摆弄意大利面条代码,所以我们决定使用 REST API 插件将 WP 变成一个无头 CMS。到目前为止,它似乎是一个非常好的选择,我将来肯定会再次使用它。
对我来说,看起来有人重新发现了 RSS/Atom 提要并将其与 REST 类似的 URL 相结合。并在上面放了一个闪亮的 JS 框架,因为现在是 2016 年了 :)
但说真的,我认为我们正在朝错误的方向发展。具有良好语义标记的 HTML 将是一个更好的解决方案。或者如何创建一个 CMS/任何系统,它根据客户端请求的 Accept 标头字段以多种格式提供相同的内容?就像一个具有 HTTP、XML、JSON 等端点的 API。
是的!就像一个无头 CMS!;)
嗯,有点像。听起来你更像是 rss.js 类型的规范——我们考虑过将其用于 WordPress 核心,但最终被取消了,因为它感觉像是对适当的 REST API 和现有 RSS 提要之间的一种妥协。
https://core.trac.wordpress.org/ticket/25639
我们在 http://www.rooftopcms.com 构建了一个 WordPress API 优先 CMS,并且已经在 Rails 中构建了一些网站(例如,请查看 http://www.hightide.org.uk)。如果您想自己使用它,我们已经开源了它。
我们为 https://twit.tv 构建了一个无头 Drupal 网站,其中包括一个基于 Drupal 7 和 RESTful 模块构建的内容 API。
阅读更多
https://fourkitchens.com/our-work/twit-tv/
http://fourkitchens.com/blog/article/twittv-launches-content-api-and-headless-drupal-site
一个自托管的开源替代方案:Cockpit – http://getcockpit.com