Headless WordPress 还不够（这里缺少的内容）

Source: Dev.to

Headless WordPress 的承诺

当我第一次转向 Headless WordPress 时，感觉像是一次巨大的升级：

• 再也没有主题的限制。
• 它就能正常工作。

隐藏的复杂性

做了几个项目后，我注意到一个新问题。Headless WordPress 去掉了一层复杂性……但它把这层复杂性转移到了别处。现在前端需要负责：

• 获取数据
• 组织响应
• 处理身份验证
• 在各端点之间保持一致性

如果你构建多个前端，就会 每次 都重复这些逻辑。

Headless WordPress 做得好的地方

• UI 的解耦
• 提升性能（尤其是配合静态站点生成器）
• 前端灵活性

这些都是实实在在的好处，但它们并没有回答一个问题：应用逻辑应该放在哪里？

脆弱的默认架构

典型的设置：

Frontend → WordPress REST API

简单，却很脆弱。前端变成了：

• 数据层
• 逻辑层
• 表现层

一次性兼顾所有角色。

引入应用层

为了避免重复和脆弱，我加入了一个中间层：

Frontend → Application Layer → WordPress

应用层提供的功能

• 标准化的数据访问
• 集中的业务逻辑
• 可复用的行为

KiwiPress：定义缺失的层

KiwiPress 是我对这层中间层的正式化尝试。与其让每个前端直接与 WordPress 对话，不如让它们与结构化的服务交互：

• WPRead – 读取操作
• WPCreate – 创建操作
• WPUpdate – 更新操作
• WPDelete – 删除操作

每个服务都有明确的职责，消除了重复和对逻辑所在位置的猜测。

KiwiPress 方法的好处

• 前端之间不再重复逻辑
• 数据处理保持一致
• 跨项目更易扩展
• 行为的唯一真实来源
• 前端更简洁
• 更容易切换渲染策略

现在我可以在以下之间切换：

• 静态构建
• 单页应用（SPA）
• 服务端渲染应用

……而无需重写核心逻辑。

与静态站点生成器的互补

KiwiPress 并不取代 Next.js、Astro 或 Gatsby 等 SSG 框架；它们是互补的。

• SSG 负责渲染、性能和交付。
• KiwiPress 负责结构、逻辑和一致性。

结论

Headless WordPress 是向前迈出的一步，但并非终点。如果 WordPress 仅充当数据层，我们仍然需要定义应用层——这正是我正在构建的方向。Headless 解决了分离问题；结构仍然是我们的责任，而这往往是最容易出问题的地方。